2,000 Greater & Lesser Mysteries

home *** CD-ROM | disk | FTP | other *** search

/ 2,000 Greater & Lesser Mysteries / 2,000 Greater and Lesser Mysteries.iso / computer / virus / mys00492.txt < prev next >

Wrap

Text File | 1994-06-10 | 296.5 KB | 6,226 lines

========================================================================= Date: Mon, 2 May 88 08:05:15 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> Comments: Resent-From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1> Comments: Originally-From: WHMurray@DOCKMASTER.ARPA From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1> Subject: Viruses: another perspective Here's a VIRUS-L submission that was forwarded to me: Ken ------------------------------------------------------------------------ = Kenneth R. van Wyk = If found wandering aimlessly, = = User Services Senior Consultant = please feed and return... = = Lehigh University Computing Center =-------------------------------= = Internet: <LUKEN@VAX1.CC.LEHIGH.EDU> = This just in: = = BITNET: <LUKEN@LEHIIBM1> = Humptey Dumptey was pushed! = ------------------------------------------------------------------------ ----------------------------Original message---------------------------- One should not be surprised that the discussion of viruses by computer users should focus on how to protect their own systems. However, as I read RISKS I become concerned that is how the problem is perceived. A virus is a special case. It is a social disease. It attacks not only a target system, but a population of systems, and social order all at the same time. I am sure that if you have imported one into your system and if it does something destructive, you will see primarily in terms of the destruction that it does. However, similar damage could have been done by any Trojan Horse or even by your own error. The problem with the virus is not in the damage that it does to one system, but with the damage that it does to a population and to the fabric of trust that is essential to the sharing of programs and other data and to commerce in general. Suppose that viruses become so pervasive that even those who have never seen one become afraid to use any program that they did not write themselves. Suppose that because of the publicity received by viruses, the public at large were to loose confidence in all computers, in the information they generate, and in information in general. If you think that that is far-fetched, then I ask you to think back to the panic that followed the Tylenol contamination. In a society in which 1500 hundred people a year die early because of the use of asbestos, another 15000 from the use of fossil fuels, 40,000 from the use of the automobile and 200,000 from the use of tobacco, the level of concern was out of any realistic proportion to the number of deaths. But it was not out of proportion to the effect of the loss of confidence in the medicine supply or even of the food supply. I suggest that it was the unconscious concern for the effects of the potential loss of confidence that caused the panic. The perpetrators of the virus know very well how it will behave in the target system, but they have no idea how it will behave in the population. The XMASCARD program did not do any damage in the user's machine, but it brought a multi-million dollar network to its knees. The scope and sensitivity of that network was not only beyond the perpetrator's knowledge, but it was beyond his comprehension. The perpetrators of these toys are, like the sorcerors apprentice, playing with powers far beyond their knowledge or control. The potential for damage is far beyond their puny powers to predict, skills, motives, or their intent. They are toying with the mechanisms of cooperation and coordination that characterize humanity. They are to be pitied for their ignorance, but they are not to be tolerated, much less admired or emulated. A society that depends for its own proper functioning upon any mechanism, dare not tolerate any interference with the intended operation of that mechanism. Bill Murray WHMurray at DOCKMASTER ========================================================================= Date: Mon, 2 May 88 08:05:47 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> Comments: Resent-From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1> Comments: Originally-From: WHMurray@DOCKMASTER.ARPA From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1> Subject: "Write-protection" for hard disks And another forwarded submission: Ken ------------------------------------------------------------------------ = Kenneth R. van Wyk = If found wandering aimlessly, = = User Services Senior Consultant = please feed and return... = = Lehigh University Computing Center =-------------------------------= = Internet: <LUKEN@VAX1.CC.LEHIGH.EDU> = This just in: = = BITNET: <LUKEN@LEHIIBM1> = Humptey Dumptey was pushed! = ------------------------------------------------------------------------ ----------------------------Original message---------------------------- On April 22, 1988 I received two back issues of a newsletter entitled "Computer Virology" along with a product description for the Disk Defender (tm). "Computer Virology is published in Evanston, Illinois by Director Technologies, Inc. Director Technologies is the manufacturer of DISK DEFENDER, a product which write protects in hardware all or part of a personal computer hard disk. It is our belief that hardware write protection is the only 100% reliable virus protection for the operating system and commonly used programs." If you have any comments, questions, suggestions or article submissions, please address them to:" Director Technologies, Inc. Technology Innovation Center 906 University Place Evanston, IL 60201 312-491-2334 [Quoted without permission from the masthead of the newsletter. I am in no way associated with this firm. This is not a recommendation or endorsement of their product.] The product appears to be a half-card that installs between the drive and the hard disk drive controller card. It can make a portion of the or all the hard disk "write-protected." It has an outboard component with a 3-position switch which permits you to select between "full|zone|none." The outboard switch can be removed in order to remove the discretion from the user. In other words, it is a hardware write-protect tab for a hard drive zone. The size of the zone appears to be chosen by setting dip-switches on the card itself. To suggest that it is 100% effective against a virus is to overstate. Studies in biology suggest that a virus can thrive even in a population in which a large percentage of the members are immune, if a there is sufficient commerce among the non-immune members. This is not an argument against vaccines but only a caution about the limits of their effectiveness. Depending upon design of the virus, the target system and population, and the chosen distribution vector, the effectiveness of this mechanism against the spread of the virus might vary from high to none at all. Good hygiene is the general defense against viruses, but there are limits to how effective it can be. Nonetheless, the individual can and should protect himself within those limits. Page 1 ========================================================================= Date: Mon, 2 May 88 09:32:17 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Jim Eshleman <LUJCE@LEHIIBM1> >Date: Tue, 26 Apr 88 09:39:51 CDT >From: Frank Peters <PETERS@MSSTATE> >Subject: MacIntosh Virus Information Request >To: <VIRUS-L@LEHIIBM1> Hello, We are interested in obtaining information about virus programs (both causes and cures) on the Apple MacIntosh. There seems to be information available on IBM PC problems but very information about the Mac. Is this because there are fewer virus programs for the Mac or because of smaller interest in the mac? Thanks Frank Peters Mississippi State Computer Center Jim Eshleman Lehigh University Computing Center ========================================================================= Date: Mon, 2 May 88 09:34:43 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Jim Eshleman <LUJCE@LEHIIBM1> >From: "John D. Abolins" <OJA@NCCIBM1> >To: Virus Discussion List <VIRUS-L%LEHIIBM1.BITNET@CUNYVM.CUNY >Subject: LaSalle talk of 288 April 88 concerning the "viruses" I did go to the lecture at LaSalle yesterday. I am still working on translating my quick notes into readable text. This should ready some time next week. Overall, the lecture was excellent and thourough without giving too much detail (to any unscruplous people in the audience.) After the talks by the panalists, MS-DOS anti-virus program disks were made available to the public. The disks contain public domsain and share ware software plus general virus text files. Three of the panalists work with companies which produce virus detection software. More on this later. Incidentally, if anyone on this forum is interested in any printed items from the forum or elsewhere, please leave me note. I can arrange for copies of much of these items. J. D. Abolins Jim Eshleman Lehigh University Computing Center ========================================================================= Date: Mon, 2 May 88 15:12:41 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1> Subject: (old) Amiga virus information, for what it's worth... I just found some information that I had sitting around concerning an Amiga virus. It's kind of old, but it could be interesting to some people, so here it is: --------- From: bill@cbmvax.UUCP (Bill Koester CATS) Newsgroups: comp.sys.amiga Subject: Amiga VIRUS Date: 13 Nov 87 19:32:05 GMT Organization: Commodore Technology, West Chester, PA THE AMIGA VIRUS - Bill Koester (CATS) When I first got a copy of the Amiga VIRUS I was interested to see how such a program worked. I dissassembled the code to a disk file and hand commented it. This article will try to pass on some of the things I have learned through my efforts. 1) Definition. 2) Dangers. 3) Mechanics 4) Prevention 1. - Definition. The Amiga VIRUS is simply a modification of the boot block of an existing DOS boot disk. Any disk that can be used to boot the Amiga (ie workbench) has a reserved area called the boot block. On an Amiga floppy the bootblock consists of the first two sectors on the disk. Each sector is 512 bytes long so the boot block contains 1024 bytes. When KickStart is bringing up the system the disk in drive 0 is checked to see if it is a valid DOS boot disk. If it is, the first two sectors on the disk are loaded into memory and executed. The boot block normally contains a small bit of code that loads and initializes the DOS. If not for this BOOT CODE you would never see the initial CLI. The normal BOOT CODE is very small and does nothing but call the DOS initialization. Therefore, on a normal DOS boot disk there is plenty of room left unused in the BOOT BLOCK. The VIRUS is a replacement for the normal DOS BOOT CODE. In addition to performing the normal DOS startup the VIRUS contains code for displaying the VIRUS message and infecting other disks. Once the machine is booted from an infected disk the VIRUS remains in memory even after a warm start. Once the VIRUS is memory resident the warm start routine is affected, instead of going through the normal startup the VIRUS checks the boot disk in drive 0 for itself. If the VIRUS in memory sees that the boot block is not infected it copies itself into the boot block overwriting any code that was there before. It is in this manner that the VIRUS propagates from one disk to another. After a certain number of disks have been infected the VIRUS will print a message telling you that Something wonderful has happened. 2. - Dangers. When the VIRUS infects a disk the existing boot block is overwritten. Since some commercial software packages and especially games store special information in the boot block the VIRUS could damage these disks. When the boot block is written with the VIRUS, any special information is lost forever. If it was your only copy of the game then you are out of luck and probably quite angry!! 3. - Mechanics. Here is a more detailed description of what the virus does. This is intended to be used for learning and understanding ONLY!! It is not the authors intention that this description be used to create any new strains of the VIRUS. What may have once been an innocent hack has turned into a destructive pain in the #$@ for many people. Lets not make it any worse!! a.) Infiltration. This is the first stage of viral infection. The machine is brought up normally by reading the boot block into memory. When control is transferred to the boot block code, the virus code immediately copies the entire boot block to $7EC00, it then JSR's to the copied code to wedge into the CoolCapture vector. Once wedged in, control returns to the loaded boot block which performs the normal dos initialization. Control is then returned to the system. b.) Hiding Out. At this point the system CoolCapture vector has been replaced and points to code within the virus. When control is routed through the CoolCapture vector the virus first checks for the left mouse button, if it is down the virus clears the CoolCapture wedge and returns to the system. If the left mouse button is not pressed the virus replaces the DoIO code with its own version of DoIO and returns to the system. c.) Spreading. The code so far has been concerned only with making sure that at any given time the DoIO vector points to virus code. This is where the real action takes place. On every call to DoIO the virus checks the io_Length field of the IOB if this length is equal to 1024 bytes then it could possibly be a request to read the boot block. If the io_Data field and A4 point to the same address then we know we are in the strap code and this is a boot block read request. If this is not a boot block read the normal DoIO vector is executed as if the virus was not installed. If we are reading the boot block we JSR to the old DoIO code to read the boot block and then control returns to us. After reading, the checksum for the virus boot block is compared to the checksum for the block just read in. If they are equal this disk is already infected so just return. If they are not equal a counter is incremented and the copy of the virus at $7EC00 is written to the boot block on the disk. If the counter ANDed with $F is equal to 0 then a rastport and bitmap are constructed and the message is displayed. d.) Ha Ha. < Something wonderful has happened > < Your AMIGA is alive!!! > < and even better > < Some of your disks are infected by a VIRUS > < Another masterpiece of the Mega-Mighty SCA > 4. - Prevention. How do you protect yourself from the virus? 1) Never warm start the machine, always power down first. (works but not to practical!) 2) Always hold down the left mouse button when rebooting. (Also works, but only because the VIRUS code checks for this special case. Future VIRUS's may not!) 3) Obtain a copy of VCheck1.1 and check all disks before use. If any new virus's appear this program will be updated and released into the public domain. VCheck1.1 was posted to usnet and will also be posted to BIX. ( Just like the real thing the best course of action is education and prevention!) Bill Koester -- CBM >>Amiga Technical Support<< UUCP ...{allegra|burdvax|rutgers|ihnp4}!cbmvax!bill PHONE (215) 431-9355 ------------------------------------------------------------------------ = Kenneth R. van Wyk = If found wandering aimlessly, = = User Services Senior Consultant = please feed and return... = = Lehigh University Computing Center =-------------------------------= = Internet: <LUKEN@VAX1.CC.LEHIGH.EDU> = This just in: = = BITNET: <LUKEN@LEHIIBM1> = Humptey Dumptey was pushed! = ------------------------------------------------------------------------ ========================================================================= Date: Mon, 2 May 88 16:19:14 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Jim <15360JIM@MSU> Subject: anti-virus program request procedures I tried to get the lastest version of FLUSHOT, the anti-Virus/anti-Trojan progr an for MSDOS. If anyone knows the exact procedures to download that, please write to me at 15360jim@msu. Thank you! ========================================================================= Date: Mon, 2 May 88 17:23:14 +0300 Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Y. Radai" <RADAI1@HBUNOS> Subject: The Israeli viruses Loren Keim writes (25 Apr): > Israeli Virus: Not much is known. It apparently attaches itself > to all executable files, appending itself to the end of the file. > Watch for growing files. I must admit I find Loren's first sentence rather surprising. The one thing that spreads faster than a virus is news *about* the virus. And since the rather detailed report which I wrote on the Israeli virus for the Info-IBMPC digest has apparently been reprinted in about a dozen other digests and news- letters, I thought that as much was known about our virus as about others. But I guess I was wrong, so here are the details: It works in two stages: When you execute an infected EXE or COM file the first time after booting, the virus captures interrupt 21h and inserts its own code. After this has been done, every time any EXE file is executed, the virus code is written to the end of that file, increasing its size by 1808 bytes. COM files are also affected, but the 1808 bytes are written to the beginning of the file, another 5 bytes (the string "MsDos") are written to the end, and this extension occurs only once. Symptoms: (1) Because of this continual increase in the size of EXE files (apparently a bug), such programs eventually become too large to be loaded into memory or there is insufficient room on the disk (hard disk or diskette) for further extension. (2) After a certain interval of time (apparently 30 minutes after infection of memory), delays are inserted so that execution of programs takes up to 5 times as long. Also, some weird things happen on the screen. (3) If memory becomes infected when the date is set to a Friday the 13th (the next such date being May 13, 1988), any program file which is subsequently executed on that date (without rebooting first) gets deleted. (Other files may also be affected.) Note that this virus infects even read-only files, that it does not change the date and time of the files which it infects, and that while the virus cannot infect a write-protected diskette, you get no clue that an attempt has been made by a "Write protect error" message since the possibility of writing is checked before an actual attempt to write is made. Actually, this is only one of four viruses which have been discovered by us so far, although the others are apparently only annoying, not destructive. One of them is but a slight variant of the above virus; it behaves the same with respect to (1), the 30 minutes in (2) is only 30 seconds, and the erasure in (3) does not succeed, due to a bug. It is probably an earlier version of the above virus. There are several things you can do to detect, prevent, and/or eradicate this virus even without any special software. Detection: Choose one of your EXE files (preferably your most frequently executed one), note its length, and execute it twice. If it does not grow, it is not infected by this virus. If it does, the present file is infected, and so, probably, are some of your other files. (Another way of detecting this virus is to look for the string "sUMsDos" starting in the 4th byte of COM files or about 1800 bytes before the end of EXE files; however, this method is less reliable since this string can be altered without attenuating the virus. In the variant, the corresponding string is "sURIV 3.00".) Prevention: In addition to the usual general precautions, avoid running programs on any Friday the 13th. Of course, you can fake the date. But if your computer has been set to Friday the 13th by a clock-calendar card and one of the programs in your AUTOEXEC.BAT file is infected, it will be too late to change the date after completion of AUTOEXEC. Cure for infected files: Replace each infected file by a healthy copy (if you have one). However, note that even if you succeed in replacing all infected files, the virus will recur if memory remains infected, so re-boot immediately after replacement. The two other viruses have April 1 as their target date. One of them affects only COM files while the other affects only EXE files. If the date has been set to April 1, they display the message "APRIL 1ST HA HA HA YOU HAVE A VIRUS". In the EXE version this happens as soon as any infected EXE file is executed, whereas in the COM version it happens only after (1) an infected COM file is executed, thereby infecting memory, and (2) any other COM file is executed. In either case they lock up, forcing you to cold boot. Moreover in the EXE version there is also a lockup, without any message, one hour after infection of memory on any day on which you use the default date of 1-1-80. However, to the best of our knowledge they do not destroy any information. In both versions the file is extended only once. The main identifying string (corresponding to "sUMsDos" in the Friday the 13th virus) is "sURIV 1.01" in the COM version and "sURIV 2.01" in the EXE version. As a curiosity, all three viruses which attack EXE files write the year "1984" into the 19th and 20th bytes of each EXE file which they infect (in the form 84h 19h), replacing the checksum which normally appears there. I hadn't heard of any occurrence of these four viruses outside of Israel until I read (in Joseph Beckman's message of 29 April) that Fred Cohen stated that the Hebrew U. virus (presumably meaning the original Friday the 13th virus) has spread to the U. S. Automatic detection, prevention and cure: A pair of programs has been developed for these viruses by Yuval Rakavy, a student in our Computer Science Dept., and Omri Mann. One of them, UNVIRUS, cures already infected files by removing the virus code; it is specific to these four viruses. The other one, IMMUNE (a RAM-resident program), prevents future infection of memory and dis- plays a message when there is any attempt to infect it; it may also be useful against some other viruses. There are, of course, general-purpose programs which prevent file infection by preventing writing and formatting of disks when such protection is desired. I guess BOMBSQAD is sufficiently well known that I don't have to describe it. Another program, PROTECT, prevents writing onto specific drives (e.g. C:). (I have a slightly improved version of the program which first appeared in the Jan. 13, 1987 issue of PC Magazine.) The protection is easily toggled on and off (even when you're not on the DOS command level if you've got something like HOT-DOS available). The weakness of programs such as these is that a virus or Trojan horse could issue a write or format command directly to the controller of a hard disk. A more secure protection would be a hardware device placed between the controller and the drive. I am familiar with one such device, called Disk Defender. It involves dividing the hard disk into two logical drives in any desired size ratio, one of which is protected against *all* writes, while the other is unprotected. (You can easily unprotect the protected drive temporarily in order to transfer files to it.) The trouble with this system is its initial incon- venience: it requires a complete reorganization of your hard disk (moving all files and subdirectories into two separate directories according to whether they are to be protected or not), followed (and preferably also preceded) by a complete backup of the disk, followed by a re-format of the disk and restoration of its contents. * * * * * The above-mentioned authors of the Israeli anti-viral software have now developed a program which can detect infection of a file by *any* virus. Probably most of you don't believe that such a thing is possible. But this report is already getting too long, so I'll leave the description of that program to a subsequent report. Y. Radai Computation Center Hebrew Univ. of Jerusalem RADAI1@HBUNOS.BITNET ========================================================================= Date: Mon, 2 May 88 16:48:11 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "David M. Chess" <CHESS@YKTVMV> Subject: The Israeli viruses > (Other files may also be affected.) Do you have anything in particular in mind when you say that? I've heard from people who have done quite a bit of work disassembling the creature that only EXE and COM files are altered. Have you heard of it changing any others? DC ========================================================================= Date: Mon, 2 May 88 15:34:39 EST Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Joe Simpson <JS05STAF@MIAMIU> Subject: Miami computer virus infection THIS IS A FIRST DRAFT OF A POSTING TO THE VIRUS-L LISTSERV GROUP. PLEASE RESPOND WITH EDITORIAL COMMENTS. MIAMI UNIVERSITY WAS HIT BY AN OUTBREAK OF MS-DOS AND MACINTOSH VIRUS APPROXIMATELY 10 DAYS BEFORE THE END OF SEMESTER. VIRUS APPEARED IN VIRTUALLY EVERY MICRO LAB ON CAMPUS WITHIN 2 DAYS OF FIRST NOTICE. THE IBM VIRUS APPEARED TO BE A VARIANT OF BRAIN. THE MAC VIRUSES APPEARED TO BE IDIOT AND SCORES. SCREENING PROCEDURES WERE INSTITUTED IN THE LABS TO DETECT AND QUASH VIRUS INFECTED DISKETTES. DETECTION BECAME MORE ACCURATE OVER TIME. THE PROCEDURE USED TO DISINFECT DISKETTES IS: 1) COPY DATA FILES (WP, SPREADSHEET, DATABASE) TO "CLEAN MEDIA" 2) FORMAT INFECTED DISKETTE ABANDONING ANY DOS AND OTHER EXECUTABLE FILES. 3) COPY DATA FILES BACK ONTO THE USER DISKETTE. THERE IS SOME REASON TO BELIEVE THAT THIS PROCEDURE IS OVERLY CAUTIOUS. IN THE MS-DOS WORLD: SCREENING PROCEDURES STARTED WITH LOOKING FOR THE WORD "BRAIN" IN THE DISKETTE LABEL. NOW WE LOOK FOR THREE OR MORE CONTIGUOUS BAD SECTORS USING SOMETHING LIKE THE NORTON UTILITIES. A STUDENT HAS WRITTEN A PROGRAM TO LOOK FOR VIRUS IN RAM. THE SAME STUDENT IS ATTEMPTING TO REVERSE ENGINEER A SOLUTION. FRED COHEN FROM UNIV. CINN. HAS BEEN UP TO ASSIST US AND WOULD PROBABLY HAVE GOOD INFORMATION ON THE VIRUS IF HE HADN'T CONTRACTED ONE OF THE HUMAN VARIETY LAST NIGHT. INFECTED DISKETTES HAVE BEEN POSTED TO BOWLING GREEN FOR STUDY (AND OF COURSE TO FRED). AT THIS POINT WE ARE NOT SURE HOW LONG THE DORMANT PHASE OF THIS VIRUS WAS. IT MAY HAVE BEEN SEVERAL MONTHS. SUBJECT TO FRED'S AND THE STUDENT'S NEW INFORMATION HERE IS WHAT WE BELIEVE ABOUT THE MS-DOS VIRUS. IT IS A VERSION OF PAKISTANI BRAIN. IT PROBABLY CANNOT INFECT A HARD DISK. MORE ON THIS WHEN WE REALLY KNOW. PROPERLY INSTALLED LAN'S APPEAR TO OFFER PROTECTION(BECASE OF THE ABOVE?) IT LIVES IN THREE CONTIGUOUS CLUSTERS (FIVE SECTORS) MARKED BAD IN THE FAT. THE VIRUS INSTALLS IN HIGH RAM AND CAN BE DETECTED THERE USING STANDARD DOS CALLS. WE HAVE DISASSEMBLED APPROXIMATELY 1/3RD OF THE CODE. IT MAY INFECT THE FOLLOWING FILES: COMMAND.COM, PRINT.COM, FORMAT.COM. FRED HAS A CHECKSUM PROGRAM THAT WE USED TO DIAGNOSE THIS BEHAVIOR. WE HAVEN'T FOUND THE CODE THAT DOES THIS. IT DOES ALTER THE BOOT RECORD ON BOTH SYSTEM DISKETTES AND DATA DISKETTES. BOOTING, EVEN WITH A DATA DISKETTE! LOADS BRAIN INTO RAM TO SPREAD INFECTION. DAVID KARIPEDES HAS DISASSEMBLED APPROXIMATELY ONE THIRD OF THE VIRUS AND HAS COME TO THE FOLLOWING CONCLUSIONS: 1. WHEN AN INFECTED BOOT SECTOR IS PROCESSED, BRAIN LOADS IN TO 7 K AT HIGH RAM. 3K OF PROGRAM, THE BRAIN BOOT BLOCK, AND THE ORIGIONAL BOOT BLOCK ARE LOADED WITH 2 I/O BUFFERS. 2. BRAIN POINTS THE $13 DISK INTERRUPT TO ITSELF AND MEDIATES ALL DISK I/O VIA AN INTERRUPT IT INSTALLS AT $6D. BRAIN ONLY ACTS AGAINST DISK READS. PROBABLY USING A COUNTDOWN TIMER IT CHECKS THE BOOT RECORD OF THE DISKETTE WITH POSTED I/O FOR INFECTION IF NOT INFECTED IT INFECTS FLOPPIES. 3. BRAIN CHECKS THE DL REGISTER ON READS AND ONLY INTERVENES IF 0,1, OR 2. THUS, IT PROBABLY CANNOT INFECT A HARD DISK. 4. THE INFECTED BOOT RECORD LOADS BRAIN FROM THREE CONSECUTIVE SECTORS THAT ARE MARKED BAD IN THE FAT. FIVE SECTORS ARE ACTUALLY USED, 3 FOR THE EXECUTABLE CODE, ONE FOR BRAINS BOOT RECORD, AND ONE FOR THE ORIGIONAL BOOT RECORD. 5. IF RAM IS INFECTED, EVEN USING LOW LEVEL DISK UTILITIES BRAIN WILL FEED YOU THE FALSE (ORIGONAL) BOOT RECORD! 6. AT PRESENT YOU MUST COMMUNICATE WITH DAVID VIA MY BITNET ACCOUNT. 7. A STAFF MEMBER IS WRITING A DISKETTE SANITIZING PROGRAM WHICH WE WILL POST TO VIRUS-L. THE VIRUS WILL PLACE BRAIN IN THE DISKETTE VOLUME LABEL AND REMOVE IT PERIODICALLY. THUS, ABSCENCE OF BRAIN IS NOT ASSURANCE OF A CLEAN DISKETTE. SOME OF THE THINGS THAT THE PRUDENT COMPUTER USER SHOULD DO IN THE COMPUTER AGE (SAGE WISDOM SUBJECT TO FREQUENT REVISION): USE ATTRIB TO MAKE COMMAND.COM AND MANY OTHER FILES READ ONLY. THIS LIST SHOULD PROBABLY INCLUDE PROGRAMS. BACKUP, BACKUP, BACKUP, BACKUP. I KEEP A 3 WEEK ROLLING BACKUP TO PROTECT MYSELF FROM DORMANT PHASE VIRUSES AS OBSERVED IN THE MAC WORLD. WRITE PROTECT ALL ORIGIONAL DISKETTES WITHIN SECONDS OF OPENING THE SHRINK WRAP. WHEN TRANSFERRING INFORMATION BETWEEN COMPUTERS USE DISKETTES THAT CONTAIN NO EXECUTABLES (SYSTEM AND APPLICATIONS SOFTWARE). WHERE POSSIBLE BOOT FLOPPIES SHOULD BE WRITE PROTECTED. IT IS NOT KNOWN AT THIS TIME WHETHER WRITE PROTECTION IS HARDWARE OR SOFTWARE MEDIATED. WE ARE FOLLOWING UP WITH IBM. IN THE MACINTOSH WORLD WE SUSPECT THAT WE WERE INFECTED BY SCORES AND IDIOT. MAC USERS ARE MUCH MORE ATONOMOUS AND OUR INFORMATION IS NOT AS GOOD. WE ARE STILL TRYING TO OBTAIN COPIES OF INFECTED MACINTOSH DISKETTES. IN THE MEAN TIME WE ARE DISTRIBUTING KILLVIRUS, VACCINE, AND FERRET 1.1. DIAGNOSIS RELIES UPON FINDING CHARACTERISTIC SIGNATURE FILES. PRESENT RECOMMENDATIONS FOR PREVENTION INCLUDE ALL OF THE ABOVE RECOMMENDATIONS FOR THE MS-DOS WORLD PLUS RUNNING KILLVIRUS OR VACCINE. SOME THINGS WE ARE CONSIDERING FOR NEXT YEAR. ENCOURAGE STUDENTS TO EXCHANGE INFORMATION ON DATA DISKETTES THAT DO NOT INCLUDE EXECUTABLES. MORE WRITE PROTECTION AT DOS ATTRIB LEVEL AND HARDWARE LEVEL. INVESTIGATE VIRUS PROTECTION SOFTWARE. IN THE MAC WORLD WE ARE USING VACCINE AND LOOKING AT VIRUSDETECTIVE AND KILLVIRUS. INVESTIGATE VIRUS PROTECTION IN THE MS-DOS WORLD? USE LOCAL HACKS TO PERIODICALLY LOOK FOR RAM RESIDENT SOFTWARE THAT SHOULDN'T BE THERE? ========================================================================= Date: Mon, 2 May 88 16:54:24 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Peter G. Neumann" <NEUMANN@csl.sri.com> Subject: Re: (old) Amiga virus information, for what it's worth... In-Reply-To: <8805022025.AA21543@csl.sri.com> Gee, That was in RISKS-5.71, 7 December 1987! But thanks anyway. And many thanks for VIRUS-L. Should be lively for you to keep track of everything. Should I mention it in RISKS, or would that FLOOD YOU with overhead? Maintaining mailing lists is a bear, even with LISTSERVE! P. ------- ========================================================================= Date: Mon, 2 May 88 17:16:32 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: OJA@NCCIBM1 Subject: A request for virus info In a recent issue of RISKS, a Congressional aide asked for information concerning computer viruses and their possible impact on national security. If you have input concerning this subject, you can contact- Herb Lin House Armed Services Committee 2120 Rayburn House Office Building Washington, DC 20515 (215) 951-1255 J.D. Abolins ========================================================================= Date: Mon, 2 May 88 17:18:35 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Peter G. Neumann" <NEUMANN@csl.sri.com> Subject: Re: (old) Amiga virus information, for what it's worth... In-Reply-To: <8805022025.AA21543@csl.sri.com> Terrrific. I have your contribution about VIRUS-L and will post it. By the way, is it not Humpty Dumpty? P. ------- ========================================================================= Date: Tue, 3 May 88 07:06:26 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Vin McLellan <SIDNEY.G.VIN%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU> Subject: The Fate of PD Code PD need not die -- despite the virus plague; and despite the obituaries the virus threat has led so many vendor-supported publications to so (gleefully?) publish. "Public Domain" software may, however, tend to lean more into "shareware" and away from "freeware." Freeware, of course, is inherently cheapest... but now we have the problem of never really being certain that the code is clean and free of hidden danger (not in itself a new problem.) Shareware -- which circulates through the same public domain/freeware channels -- is copyrighted and typically accompanied by a request from its author for a (usually minimal) payment for licensed user rights. And, more than in the past, a shareware license will likely be accompanied by a disk with a clean copy of the purchased program. Nothing is likely to ever displace the PD circuit on the nets and bulletin boards as the cheapest and easiest way to both circulate new code and check out what's the newest. Even with infected code circulating, this can be done safely and intelligently on an isolated machine without a hard disk. Obviously, no responsible institution or group (or even an individual) is going to mix freeware code with working disks or files. The best defense against infected code is to obtain a legitimate shareware license -- and a guarranteed clean copy of the code, directly from the author. For a corporation or institution, that *contractual* link becomes essential for its internal security and ease of mind.(This may be lead to some strange scenes. More than a few programmers who just tossed out a now-popular freeware program onto a BBS system years ago may be surprised to find firms or institutions insisting on the right to pay them -- to establish a contractual relationship -- but they'll probably survive the shock.) Site or corporate licenses, now scorned by the industry, may be widely used here. In an institutional or user community, it will be up to local management to either buy enough guarranteed clean copies on disks... or arrange for trusted reproduction of an original received directly from the author. But the contract must and should be the foundation of safe software distribution. So freeware will inevitably be transformed into shareware; a craft cult into an profit-making industry sector; hackers into capitalists -- willy-nilly. (Some skateboard champs may have to open banks accounts, pay taxes, etc.) With that, Freeware/Shareware is likely to continue for the benefit of us all...and to bedevil a software industry whose pricing policies are more akin to Merlin's mumbled incantations than to any objective economic factors. Vin McLellan The Privacy Guild (Sidney.g.vin%Oz.AI.MIT.EDU@XX.LCS.MIT.EDU) Boston, Ma. 02111 (617) 426 2487 ------- ========================================================================= Date: Tue, 3 May 88 08:17:00 EST Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: J_CERNY@UNHH Subject: Question related to Macs. At the risk of exposing my ignorance, I'll ask the following question. In reading about methods to disinfect or vaccinate an infected (or suspected) system, people talk about either throwing away infected files or running code (macrophage?!) to gobble up the infected parts. In thinking of the Macintosh, I'm wondering if there is yet another place where a virus could lurk -- the parameter RAM?? I don't even know if it is possible to write into that RAM, except that I have the impression that is where date/time is stored and the fact that the CHOOSER can update/set date/time implies it can be written to. Jim Cerny, University Computing, University of N.H. ========================================================================= Date: Tue, 3 May 88 08:59:28 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1> Subject: LISTSERV options A couple people have asked me why they don't get a copy of their own submissions to the VIRUS-L list. Well, that's the default way that LISTSERV is set up. There's two ways around it; I can set up the entire list such that everyone receives their own messages, or each user can set their own LISTSERV options, at their discretion. I prefer the latter. To tell the LISTSERV program to send you your own submissions, send the following mail message to LISTSERV@LEHIIBM1: SET VIRUS-L REPRO Ok, it's a bit cryptic, but that's the way it works... :-) Note: Please do not send the above message to the list itself!!! Ken ------------------------------------------------------------------------ = Kenneth R. van Wyk = = = User Services Senior Consultant = I can't believe you fell for = = Lehigh University Computing Center = the oldest trick in the book = = Internet: <LUKEN@VAX1.CC.LEHIGH.EDU> = Lone Star! = = BITNET: <LUKEN@LEHIIBM1> = = ------------------------------------------------------------------------ ========================================================================= Date: Tue, 3 May 88 10:42:49 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Jim <15360JIM@MSU> Subject: download FSP UUEARC to Micros I have the anti-virus file call FSP UUEARC at my IBM 3090 minidisk. I try to download it to micros. Please tell what additional UNARC file(s) I need, where to get it, and procedures to actually download it. I knew the way to download regular files through KERMIT. Thank You All! /Jim ========================================================================= Date: Tue, 3 May 88 10:50:23 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1> Subject: Re: download FSP UUEARC to Micros In-Reply-To: Message of Tue, 3 May 88 10:42:49 EDT from <15360JIM@MSU> >I have the anti-virus file call FSP UUEARC at my IBM 3090 minidisk. >I try to download it to micros. Please tell what additional UNARC file(s) I >need, where to get it, and procedures to actually download it. I knew the way >to download regular files through KERMIT. Thank You All! /Jim Just a guess, but it sounds as if the file is a uuencoded arc file. Uuencode/uudecode are two programs for converting a binary file into an ascii file and then back; thus making it easier to transfer binary files over networks. Once the uuencoded file has been uudecoded, it should be a standard arc file extractable by PKXARC or ARC. You can get a copy of uudecode from SIMTEL20.ARPA if you have Internet access, or I can send you a Turbo Pascal source code version. Please reply by direct e-mail if you want the Turbo source. I assume that FSP is Flu_Shot+? I'd be happy to make copies of Flu_Shot+, uuencode & uudecode, etc. available via this LISTSERV if there's sufficient interest. Comments anyone? That's not an endorsement of public domain anti-virus programs; rather, it'd be providing a place where people on this list could download these programs with a reasonable degree of certainty as to the integrity of the program. Ken ------------------------------------------------------------------------ = Kenneth R. van Wyk = = = User Services Senior Consultant = I can't believe you fell for = = Lehigh University Computing Center = the oldest trick in the book = = Internet: <LUKEN@VAX1.CC.LEHIGH.EDU> = Lone Star! = = BITNET: <LUKEN@LEHIIBM1> = = ------------------------------------------------------------------------ ========================================================================= Date: Tue, 3 May 88 13:37:56 EST Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Joe Simpson <JS05STAF@MIAMIU> Subject: BRAIN virus We have completely disassembled virus. It behaves as previously discussed. In the absence of programming bugs it only installs itself. It definately lives in the boot block plus 3 bad sectors. It does not infect any "normal" dos files. I specifically checks for and infects 5.25 inch floppies, no 3.5 , no hard disk. We have a simple brain remover program. Source will be posted to the list (assembly language) when the author thinks it is pretty enough. Disassembly and program work done by David Karipedes, a Miami student. To contact him use my bitnet mailbox. P.S. Since we have some diskettes with evenly spaced bad clusters in them, the search is on for the existance of another virus at M.U. We really don't have useful info one way or another at this time. ========================================================================= Date: Wed, 4 May 88 09:46:00 URZ Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: BG0@DHDURZ2 Subject: European viruses") from(forum) ========================================================================= Date: Wed, 4 May 88 09:57:00 URZ Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: BG0@DHDURZ2 Subject: European viruses Hi folks, I am working on computer viruses (and protection) for 2 years now, so I hope that I can contribute some interesting facts on viruses to this list. Although the description of known computer viruses should not be the only topic of this list, I like to start with a quick summary on the viruses I know that are not mentioned here before. We here in Europe have our own "virus" culture :-) so it may be of interest for you to have a look across the atlantic: The first viruses I heard of two years ago are written to show the THREAT of computer viruses. The first one, VIRDEM.COM is a non-replacing (not overwriting), not memory-residend MS-DOS virus. It infects all .COM files on drive A: only. The damage ias to ask a user for a number between 0 and n (n is the generation of the virus) if he starts an infected program. If he was wrong, the program terminates, if he was right, the program starts its work. This program was distributed to all interested computer users, especially computer and software manufactures. The second one was written by myself. It only infects the file KEYBGR.COM (the device driver for a german keyboard of the MS-DOS version 2.11, loaded every time you boot your computer). After 15 min. it drives the internal speaker do emit noise every time a character is send to the screen (Therefore I called this virus RUSH HOUR :-) ). It was easily to be detected and removed - because it was for demonstration only. This two viruses were written in Summer 1986. Ralf Burger (the author of the first virus VIRDEM.COM) and I get contact in Aug. 1986 and we decided that it is time to inform the public (and not only professional computer users) of the *threatening* possibilities of computer viruses. In collaboration with the Hamburger CHAOS COMPUTER CLUB we organized a public forum on computer viruses on Dec. 27, 1986. That was the first time the topic of computer viruses was discussed in an open event here in Europe. We earned a lot of consolation from the press and all the people there. Four month later we had a meeting with all the folks again to see how the things are going. In the meantime the topic of viruses was discussed in nearly all german computer magazines. One magazine published a computer virus and a protection program for a 680x0 machine (Atari) called MILZBRAND. I dont know if it is good to publish a virus source code but it was not my decision. Ralf Burger started to write a virus protection program (that is available now, further comments on it see below) which should not be able *find* virus programs but to hinder the propagation of viruses on MS-DOS machines. I think he has done good work. In spring 1987 I started to think about viruses on mainframes. The result was a replacing virus for IBM/370 mainframes called VP/370 (No, I dont send you a copy of this exept you can state a *REAL* interest in it, e.g. you are a OWNER of such a machine! I dont want to be the one who is responsible for a damage I cant figure out.) Since that time I am working (nearly) exclusivly on virus protection methods. But now lets return to the viruses I know. The next virus was a virus written in high level language (TURBO PASCAL 3.xx) called NUMBER ONE. It only infects compiled Pascal programs because it needs the Pascal run time library. It is only 100 lines in size. In winter 1987 I heared of a new virus in Vienna(Austria) and has the possibility to analyse it. I wrote a flow chart generator for .COM files and was able to see how it works. Nothing special on it. Thats all I can say definitly, although a lot of rumors are out here. But I dont want to talk about rumors. Ralf edited a book about computer viruses ("Das grosse Computer- Viren Buch", will be available in English in the near future). He wrote a lot of demonstration viruses in different languages (MS-DOS Batch Language, Basic). The Internation Standard Book Number is ISBN 3-89011-200-5 for the first edition, but you better ask for the revised second edition. My next point is on protection methods. I think it is a unsatisfying work to write programs that can *detect* ALL kind of viruses. So I think it will be the best to catch viruses (that means hindering their propagation) by looking at their principles. All viruses have to *change* program code (in a file or on the disk) if they want to work the way they are designed. A straight forward method is to detect changes on files. Take a good checksum algorithm that cant be forged in a simple way. Run this program on all your files (and/or entire disk) every time you boot your machine. Make sure that the checking program is on a write protected disk (TAB!) and you can detect all changes in .COM and .EXE files. If a program has changed try to find out why. This is the method Ralf uses for his software- based protection program. An other method is to keep ALL executable files encipherd on mass storage devices, but make sure the ciphering algorithm is GOOD. GOOD means that it should be an algorithm that allows a quick decipher but a complicated encipher (trapdoor in the opposite direction, come on mathematicians: Find a good one!). Write a new program loader that deciphers loaded programs before execution. So the executable file only exists in RAM but never on storage devices. A virus program has to write its *executable* code to files on disk but this code cant be executed because it is *destroyed* by the program loader during deciphering. If the ciphering method is good (see above) a virus cant encipher itself before writing its own code to a file on disk. This method is just an idea of mine. A test version for MS-DOS machines works quite well, but I think my ciphering algorithm is not GOOD in the above sence. Of course the perfomance of loading programs slows down, so this will be satisfactory only on fast machines. The last method I want to mention is a hardware protection. It is based on optical disks (WORMs). Files on such a device cant be "overwritten" in common sence, you have to mark the old program "erased" or "unvalid" and have to store the new version somewhere else on the disk. If you have a (ROM-)program that checks where an executable file on the disk is located you are able to detect infections (or *other* changes in the software -> software revision!) because the forged program is located at the wrong place. This method is implemented in Ralf's last project and the results are encouraging. That's all for today. I hope all of you find it intersting to hear about the facts here in good ol' germany. If you are intersted in more you can have a look in a book on computer viruses (ed. by Ralf, with lot of programs and further information and a lot of articals from virus programmers, software and security managers and so on.) Its great to have a forum where the topic of computer viruses can be discussed in such an open way. Keep on the good work. All the best for you, Bernd Fix. ========================================================================= Date: Wed, 4 May 88 08:04:55 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> Comments: Resent-From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1> Comments: Originally-From: WHMurray@DOCKMASTER.ARPA From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1> Subject: ERIC and VULT identified Here's a forwarded submission: Ken ------------------------------------------------------------------------ = Kenneth R. van Wyk = = = User Services Senior Consultant = I can't believe you fell for = = Lehigh University Computing Center = the oldest trick in the book = = Internet: <LUKEN@VAX1.CC.LEHIGH.EDU> = Lone Star! = = BITNET: <LUKEN@LEHIIBM1> = = ------------------------------------------------------------------------ ----------------------------Original message---------------------------- "ERIC" and "VULT" Identified ERIC and VULT, the specific targets of the SCORES Apple MacIntosh virus, were internal projects at EDS in Dallas according to EDS spokesman Bill Wright. These labels identify proprietary trade secret programs that were once, but no longer used at EDS. While SCORES was specifically designed to destroy these applications, it would infect anything. All the above was gleaned from "Macintosh Today," May 2, 1988 which also contained a highly speculative article entitiled "Viruses: Nothing to sneeze at." If you believe this article, computers have seen their day. In the future, viruses will make them unuseable. William Hugh Murray, Fellow, Information System Security, Ernst & Whinney 2000 National City Center Cleveland, Ohio 44114 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 ========================================================================= Date: Wed, 4 May 88 08:46:38 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1> Subject: LaSalle talk A few people have asked me about obtaining any written information on last week's virus talk at LaSalle College. I'm afraid that I don't have any written summaries; does anyone out there have anything more than what's already been sent to the list? If so, please forward it to the list - it'd be much appreciated! Thanks! Ken ------------------------------------------------------------------------ = Kenneth R. van Wyk = = = User Services Senior Consultant = I can't believe you fell for = = Lehigh University Computing Center = the oldest trick in the book = = Internet: <LUKEN@VAX1.CC.LEHIGH.EDU> = Lone Star! = = BITNET: <LUKEN@LEHIIBM1> = = ------------------------------------------------------------------------ ========================================================================= Date: Wed, 4 May 88 09:33:44 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1> Subject: files are now available Well, after saying that I'd make uuencode/uudecode and Flu_Shot+ available, I got a whole lot of requests for them, so I've placed them here on the LISTSERV for public copying. The filenames are: UUENCODE PAS (note the space, *NOT* a period! This is CMS!) UUDECODE PAS FSP UUE PKX35A35 UUE FSP UUE is a uuencoded ARC file. PKX35A35 UUE is the PKARC package. PKXARC is required to unARC the files in FSP.ARC. The uuencode and uudecode files are in Turbo Pascal v 3.x. Both of these files are *shareware* and you are encouraged to send the authors the money that they request for the use of their programs - see the license agreements of each package for more information. Ok, now you probably want to try to get these files... Well, it's similar to signing onto or off of a LISTSERV group; you send a message to LISTSERV@LEHIIBM1. The message should say: GET filename filetype listname For example: GET PKX35A35 UUE VIRUS-L This would send you the PKARC package. Once you've gotten all the files that you want, you would do the following to uudecode and extract FSP: compile uudecode into a .COM file. UUDECODE PKX35A35 PKX35A35 (this step unarcs the self-extracting PKARC package.) UUDECODE FSP PKXARC FSP And after all that, you *should* have a working copy of Flu_Shot+ and PKARC. If you already have PKARC, this can be a whole lot simpler... I hope I haven't overly confused everyone. :-) By the way, you can always get a current list of all files available on VIRUS-L by sending an INDEX VIRUS-L command to LISTSERV@LEHIIBM1. Finally, please don't send any of these commands to the list itself! Enjoy, Ken ------------------------------------------------------------------------ = Kenneth R. van Wyk = = = User Services Senior Consultant = I can't believe you fell for = = Lehigh University Computing Center = the oldest trick in the book = = Internet: <LUKEN@VAX1.CC.LEHIGH.EDU> = Lone Star! = = BITNET: <LUKEN@LEHIIBM1> = = ------------------------------------------------------------------------ ========================================================================= Date: Wed, 4 May 88 10:46:53 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1> Subject: PC security programs Here's another forwarded submission to the list: From: <GREEN@wharton.upenn.EDU> "Scott D. Green, Classroom Services" Return-path: GREEN@wharton.upenn.EDU Date: Wed, 4 May 88 10:10 EST From: "Scott D. Green, Classroom Services" <GREEN@wharton.upenn.EDU> Does anyone have any experience with hard disk security software? Two that we have for evaluation are "DiskManager PC" and "PC/DACS." Both claim to be able to prevent a drive or just directories and files from being tampered with. Out goal is to try to minimize software maintenance on public lab machines by limiting students' write privileges to the hard dirve, protecting batch files, etx. Both packages claim to superced DOS attrib commands and foil Norton Utilities. They also provide "boot lock": if you boot from a floppy, the hard drive does not exist for you. Though they don't specifically mention virus protection, it seems a reasonable side effect. [I've been evaluating PC/DACS, and it looks pretty nice, although it's not specifically targetted as being an anti-virus program. It gives a PC security much like on, for example, a VAX, whereby you can have separate users - each with different access to different drives/directories/files/resources. It includes boot protection and full disk encryption. If you don't install all the boot protection and encryption features, it's *VERY* easy to get around. This is not an endorsement of this product - merely a statement of its features. - Ken ] ------------------------------------------------------------------------ = Kenneth R. van Wyk = = = User Services Senior Consultant = I can't believe you fell for = = Lehigh University Computing Center = the oldest trick in the book = = Internet: <LUKEN@VAX1.CC.LEHIGH.EDU> = Lone Star! = = BITNET: <LUKEN@LEHIIBM1> = = ------------------------------------------------------------------------ ========================================================================= Date: Wed, 4 May 88 10:10:00 CDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: GREENY <MISS026@ECNCDC> Subject: Viral Code Hi all.... I have recently been given the task of making sure that all of the software and/or data that we have in my department is clean and free of viruses. Due to the fact that I feel that I can't really trust anyone's outside applications anymore without source code (that I'm able to comprehend as well..), I ahve decided to write my own stuff. But what I need is the means to test it out. Copies of the SCORES and/or IDIOT viruses for the macintosh would be very helpful as we have a number of Macs here, viruses for the IBM PC would also be helpful as there are even more IBM's in the dept (much to my chagrin! :-> ) At any rate, I am willing to get copies of the virus(es) via EMAIL, US Mail, tape, or whatever, and once written I will post copies of my disinfectioon programs to the net -- along with the source code. Any help would be greatly appreciated. bye for now but not for long... David S. "Greeny" Greenberg Departmental Technician Department of Learning Resources Western Illinois University Bitnet: MISS026@ECNCDC Internet: MISS026%ECNCDC.BITNET@CUNYVM.CUNY.EDU Disclaimer: My department takes no responsibility for what I say....it's all supposed to be my opinions.... ========================================================================= Date: Wed, 4 May 88 12:12:00 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Dr. Woody" <WWEAVER@DREW> Subject: COREWARS, the Scientific American game implemented on a macintosh Greetings everyone, There was some inquiry into the Scientific American game "CoreWars". I've a version for the macintosh. The help manual gives a pretty good feel for what the game is about. The program is shareware, and the manual includes the authors name and address - I don't know if it is still current, but the author says he will send you the source code (in C) for $15. The file is a trifle long, so I will send it to the list moderator - he can then put in on the list or in the archives (or throw it away :-) ) as he sees fit. woody WWEAVER@DREW * This is not an endorsement of the product - I've never played it, except to verify that it ran (on a 512K mac with an old system). But if we ever succeed in getting viruses off of disk storage and force them to live in RAM, COREWARS is an interesting metaphor. * ========================================================================= Date: Wed, 4 May 88 18:10:15 PDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Joseph Sieczkowski <joes@scarecrow.csee.lehigh.edu> Subject: Brain Virus info I have some specific information on the brain virus. I'd though that I'd share it with you by forwarding it to the list. Also, I'm sending the source code to programs called "nobrain.c" and "checkmem.c" to the owner of the list so he can make them publically avalible. Nobrain supposedly finds and kills the brain virus if present (memory and floppy). And checkmem is just a utility to see if its resident. Hope this is helpful, ------------------------------------------------------------------------------ Comments on the "(c) Brain" Virus The virus is benign. All it does is propogate itself. The only way it can spread is by booting an infected diskette. Once booted, the virus installs itself in memory and will proceed to infect an DSDD floppies it can "find". Diskettes When infecting a diskette, the virus replaces the boot record (trk 0, side 0, sect 1) with its own boot record. This is the code that actually installs the virus into memory. It then locates 3 "free" clusters from the FAT, loads the actual virus code into those clusters along with a copy of the "real" boot record, and then marks those 3 clusters as "bad". Finally, it installs a diskette volume label of "(c) Brain" on the infected diskette. However, the volume label format isn't 100% correct so utilities such as Norton's will show it as a "bogus" directory entry format but DOS will display it. In the 3 custers (6 sectors), the "good" boot record is in the first sector and the virus itself is in sectors 2-6 of the 3 clusters. (Actually, the virus doesn't apprear to need all that space). Operation - looks to see if infected (1234H will be in 0004 & 0005 of record) - it will load itself into the last 7K of ram and then set the DOS available ram value down by 7... eg 640 will become 633, so that the virus in memory will be "safe". - changes the disk read/write vector (13 Hex) to point to his virus - stores the original 13H vector at a new vector (6D hex) which he invokes when a "real" read or write is needed. - the original boot record is moved to the 1st sector of the 3 bad clusters he as marked (so he can still boot the PC after he has done his "dirty work") - his boot code is installed in original boot record location (Trk Hd Sct = 0 0 1). - 3 free clusters found, virus and boot rec place here, and marked as bad. - while checking FAT, he checks ID byte to insure that this is a DSDD diskette... won't infect any other kind (which also precludes hard drives) - His "(c) Brain" label is written but he allows for the 2 hidden bios (he doesn't check if they are present). The result is, if a completely empty diskette is infected, the label doesn't show up until at least 2 files are on the diskette. At this point diskette is completely infected. His infection of new diskettes is sort of random or "haphazard". - If a disk write occurs, he allows it to proceed as usual. - After 32 disk reads, he will infect a diskette and then every 4 reads there after... UNLESS, it is a read of trk 0 side 0 (ie directory area, FAT, etc.). Then he immediately checks if infection is needed and does so if not already infected. He resets the 4-counter at this point. This results in the virus spreading rather quickly while somewhat reducing the noticable degradation from the virus' overhead... tho' it can be seen if you are looking for it) That's about it. If you are reading this, I hope it was of some use. Carl Fussell ------------------------------------------------------------------------------ ========================================================================= Date: Thu, 5 May 88 08:25:29 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1> Subject: new files available I just posted three new files to VIRUS-L. They are: DIRTY DOZEN NOBRAIN C CHECKMEM C Thanks to James Ford for sending in the Dirty Dozen list, and to Joe Sieczkowski for sending in the anti-Brain programs. The Dirty Dozen is the "standard" listing of known trojan/virus programs. The two C files are as Joe described - Brain killers. I don't have a Brain damaged :-) disk to test these with, so I'd appreciate any comments (e-mail them to me please) from anyone who tries them out. Thanks again guys! Ken ------------------------------------------------------------------------ = Kenneth R. van Wyk = _ /| = = User Services Senior Consultant = Ack Thippfft! \'o.O` = = Lehigh University Computing Center = =(___)= = = Internet: <LUKEN@VAX1.CC.LEHIGH.EDU> = U = = BITNET: <LUKEN@LEHIIBM1> = Bill 'n Opus in '88! = ------------------------------------------------------------------------ ========================================================================= Date: Thu, 5 May 88 10:52:00 EST Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: J_CERNY@UNHH Subject: The Shockwave Rider. As a "literary" note on viruses, I thought some readers might be interested in a few quoted fragments from John Brunner's science fiction novel THE SHOCKWAVE RIDER. TSR was published wayyyy-back in 1975! One of the interwoven, though somewhat obscure, themes is of computer worms and viruses used to protect and attack computer data. [p. 24] "Then the answer dawned on him, and he almost laughed. Fluckner had resorted to one of the oldest tricks in the store and turned loose in the continental net a self-perpetuating tapeworm ... . It could take days to kill a worm like that, and sometimes weeks." [p. 25] "Promptly he sent a retaliatory worm chasing Fluckner's. ... According to recent report, there were so many worms and counterworms loose in the data-net now, the machines had been instructed to give them low priority unless they related to a medical emergency." [p. 173] " ... I'd have written the worm as an explosive scrambler, probably about half a million bits long, with a backup virus facility and a last-ditch infinitely replicating tail." [p. 174] "What you need is a worm with a completely different structure. The type they call a replicating phage. And the first thing you must give it to eat is your original worm." Jim Cerny, University Computing, University of N.H. ========================================================================= Date: Thu, 5 May 88 10:45:00 CDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: GREENY <MISS026@ECNCDC> Subject: A thought... Internet: MISS026%ECNCDC.BITNET@CUNYVM.CUNY.EDU Disclaimer: #include<std_legal_mumbo_jumbo.h> What with all of the recent discussions on how giving out viral code and copies of viruses being dangerous, it occured to me that this could be true. An unscrupulous person could very well pervert such code for his/ her/it's own purposes. The solution that most of netland has seemed to arrived at is to not distribute such code, but to distribute the techniques for removing viruses from systems, as well as source code for such removal. Now stop and think about this for a minute, if I am given the technique for removing some infection, it also tells me HOW TO INFECT the system in a similar manner by exposing weak points in the OS. This is as good as releasing the virus in question, and any unscrupulous persons out there with a modicum of intelligence will be able to engineer a virus (which may or may not be even more potent than the one being destroyed...) from the provided information. Therefore, it makes just as much sense not to release any techniques on how to kill the viruses as well as programs that do the actual removal (they could be disassembled and perverted as well). Of course, this is all not possible, since we all must work together in the eradication of these beasties, and as such viral code and viruses should be released to the general public if we are to be able to work on a cure to this problem. You don't see the US government saying "well AIDS is pretty nasty stuff, no one can touch it but us, and we'll get back to ya with our results later..." --- EVERYONE IS WORKING TOGETHER on the eradication of that deadly disease and it should also be such with computer viruses.... * flame off * Bye for now but not for long Greeny Bitnet: MISS026@ECNCDC ========================================================================= Date: Thu, 5 May 88 13:03:14 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> Comments: In-Reply-To: Message of Thu, 05 May 88 12:04:28 EDT from <MISS026@ECNCDC> From: "David M. Chess 862-2245" <CHESS@YKTVMV> Subject: A thought... That's probably a good philosophical point, but the practical point behind it isn't quite true. Since the only "weaknesses" that a virus needs to exploit are things like "it's possible for a program to alter another program" and "it's possible to start a process that can intercept I/O calls to the OS", and since those are things that most programmers already know, anti-virus programs don't have to "give away" anything that would help a virus writer. One typical kind of virus-detector just notices (by a checksum or whatever) what executable files have changed since the last time it was run. All that reveals about viruses is that some of them change executable files. More specific anti-virus programs look for certain (meaningless-in-isolation) data in certain places in executable files, and tell you that the file is infected with Virus X if it finds it. All that reveals is that, for instance, "some virus puts the bytes F1 02 97 BC 00 90 at offset 011E in infected COM files" (no, that's not a real example). So it is possible to distribute a certain amount of anti-virus information without spreading any how-to-write-a-virus information. (Note that I have carefully avoided giving any opinion about whether any of the latter sort of information ought to be spread!) Dave Chess Watson Research * Nothing in this posting is an Official Statement of anybody, * whether I work for them or not. ========================================================================= Date: Thu, 5 May 88 16:04:00 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1> Subject: Another file available I've posted another file here on VIRUS-L. The filename is: RISKS LOG It contains a complete set of all of the computer virus discussions that have taken place on the RISKS forum over the past year or so. The file is very large, so it was not a good idea to send it to the entire list. Because of the file size, please only retrieve this file if you *really* want it, just to keep unnecessary network traffic to a minimum. For the benifit of newcomers to the list, you can retrieve a file on the list by sending a message to LISTSERV@LEHIIBM1 containing: GET filename filetype For the above file, RISKS LOG, you would send: GET RISKS LOG To get a list of available files, send, also to LISTSERV@LEHIIBM1: INDEX VIRUS-L The available files include a per month log of all of the messages sent to VIRUS-L. Ken ------------------------------------------------------------------------ = Kenneth R. van Wyk = _ /| = = User Services Senior Consultant = Ack Thippfft! \'o.O` = = Lehigh University Computing Center = =(___)= = = Internet: <LUKEN@VAX1.CC.LEHIGH.EDU> = U = = BITNET: <LUKEN@LEHIIBM1> = Bill 'n Opus in '88! = ------------------------------------------------------------------------ ========================================================================= Date: Thu, 5 May 88 16:07:00 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: EAE114@URIMVS Subject: DISSEMINATING SOURCE CODE Greeny <MISS026@ECNCDC> comments that it is possible to analyze the code for a virus hunter, and thereby develope another, more virulant virus. By way of analogy, he comments that the US government has not declared a monopoly on AIDS research. - - Initial Reaction: Good point. However, while there is no monopoly on the virus, there IS a definate effort to restric access to samples of the virus itself, and rightly so. In terms of distributing source-code of viruses (Virae?) If I have the source code to a virus-killer, I can reverse engineer it, and get a virus; OR i can run it, as is, to hunt viruses. If I have the source code for a VIRUS, I can reverse-engineer it, to make a virus-killer; OR i can run it as is, to infect other systems. - Since I can distribute code that makes it EASY to hunt viruses, and HARD to create them, why distribute code that does the reverse? The only reason I can see for wanting a virus is to test your virus killer, and it seems as if, if you're good enough to write the killer, you ought to be able to write the virus from the description. (PRose: EAE114@URIMVS) ------------------------------------------------------- Disclaimer: My opinions are supported, dictated, and ghost- written by the University, the state, the federal government, The CIA, and the POPE. If you don't like it, sue them. ========================================================================= Date: Thu, 5 May 88 16:44:00 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1> Subject: Virus source code I suppose we can argue until our fingers bleed as to why or why not distribute source code to viruses; and there are probably valid arguments for both sides. But, as a matter of somewhat arbitrary policy, I don't think that virus source code should be distributed to the list. Discussion of *how* a particular virus works is great, but distributing the source code is, in my opinion, not a good idea. Distributing source code to a program which "hunts and kills" viruses, however, could be benificial because it is for the common good. So, that's the official standpoint. Comments/suggestions/flames are invited *IF* you e-mail them to me directly and not to the list; it *is* possible to change policy. But, I feel that we've had enough discussion on this matter on the list already. Everyone made good valid points... Ken ------------------------------------------------------------------------ = Kenneth R. van Wyk = _ /| = = User Services Senior Consultant = Ack Thippfft! \'o.O` = = Lehigh University Computing Center = =(___)= = = Internet: <LUKEN@VAX1.CC.LEHIGH.EDU> = U = = BITNET: <LUKEN@LEHIIBM1> = Bill 'n Opus in '88! = ------------------------------------------------------------------------ ========================================================================= Date: Thu, 5 May 88 09:35:00 URZ Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: BG0@DHDURZ2 Subject: Virus Construction Set Hi folks, bad news from Germany. I have forgotten to tell you something in my last message: Not all people concerned with computer viruses (esp. virus programmers) over here are aware of what they are doing. In April this year a unbelievable program called "VIRUS CONSTRUCTION SET (VCS)" was released at the Hannover computer faire CeBIT. The VCS is a program written for the Atari ST series and allows *EVERY* Atari user to create his "own" virus. The program is menue driven - you can select different infection methods, damage initialisers, damages, and target files. You dont have no know how a virus work to create one, you just have to know how to turn on your Atari and how to start the VCS program!!! No further comments -- All the best to you all, Bernd. ========================================================================= Date: Thu, 5 May 88 12:32:36 EST Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Joe Simpson <JS05STAF@MIAMIU> Subject: Ethics and information I'd like to respond to three thoughts posted to virus-l. 1. The virus that kills the virus. At first thought seems anathema, but I see no problem with it if it follows the ethical restraint: It must not write to a disk without the explicit permission of the disk operator. This includes, of course, "virus removal." 2. There has been a lot of discussion about the need to hide information, and especially code, permitting easy development of viruses. My personal opinion is that it requires little imagination and readily available information to write a virus. Say $30 in manuals and some simple hacking around. If this opinion is accurate, hiding information has little benefit. 3. There is an opinion that no one should download code from bulletin boards. Only source code should be distributed. For most people a virus hidden in source code is just as undetectable as a virus hidden in a machine image. I hope that this opinion will not prevent virus-l from storing useful machine images. If computing society becomes overly protective in response to this anti-social behavior, then we all loose. The analogy with radical revolutionary doctrine is straigforward. ========================================================================= Date: Fri, 6 May 88 12:31:00 LCL Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Michael Wagner new! +49 228 8199645 <WAGNER@DBNGMD21> Subject: Re: A thought... A number of things were said in this posting that were addressed by others, so I won't repeat it, but one bears comment still: > From: GREENY <MISS026@ECNCDC> > > ...we all must work together in the eradication of ...(viruses)... > You don't see the US government saying "well AIDS is pretty nasty > stuff, no one can touch it but us, and we'll get back to ya with > our results later..." Actually, that is exactly what I saw the US government doing for the longest time. In fact, for several years, the government solution to AIDS was 'a hope and a prayer'. Stop promiscuity and AIDS will go away by itself. And besides, AIDS only strikes people who are non-white, or homosexual or drug abusers. Nothing there for decent people to worry about. Why should we research the thing? Why should we provide care for the afflicted? Nobody we care about is affected! > --- EVERYONE IS WORKING TOGETHER on the eradication of that deadly > disease and it should also be such with computer viruses.... This is a relatively new phenomenon that real research is being done on AIDS, and recent studies have shown that the delay will be responsible for untold deaths. The stakes are clearly different with computers, but the idea isn't much different. Work done now to understand and limit virus spread will save much pain later. Michael ========================================================================= Date: Fri, 6 May 88 08:42:58 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1> Subject: A reader's description of LaSalle talk. I just got this description of the LaSalle virus seminar from J.D. Abolins - thanks J.D.! Ken ----------------- Computer Virus Seminar at La Salle University reported by J.D. Abolins OVERVIEW (Philadelphia,PA) On Thursday, 28 April 1988, the Philadelphia Area Computer Society (PACS) and La Salle University Academic Computing presented a seminar on computer viruses. The panelists for the seminar were- - John Hagman, a Personal Computer (PC) Support Analyst with the Phildelphia Electric Company (PEC) - Donald Montabana, a MacIntosh and PC support specialist at the University of Pennsylvania - Steve Weissman, vice-president of PACS and a systems operator (sysop) for one of PACS bulletin borard system's (BBS) sections. - Raymond Glath, president of RG Software Systems, Inc. - Pam Kane and Andy Hopkins, both from Panda Systems. Steve Longo, the president of PACS and the director of La Salle University Academic Computing, moderated the seminar. The panelists took turns speaking, Instead of using a rigid, subject-based outline for the presentations, the presentations focused on the speakers' own experiences and viewpoints. At certain points, the audience was given a chance to ask questions and to make comments. The audience participation was lively. (15 minutes before the seminar began, there were only a few people in the audience but by the time the seminar got under way, the room was filled.) After the seminar, copies of virus literature was distributed. PACS had an anti-virus/anti-Trojan programs disk available for purchase. THE PRESENTATIONS RAY GLATH: Ray Glath, the first speaker, told how when he started working with computers over 20 years ago, there were some cases of malicious programs. But in those days, those programs did not go far. Today, several factors have contributed to the ability of such programs to move rapidly. First is the proliferation of the microcomputers; in short, there are far more computers than in 1964. The other factor is the "pass around" attitude towards software along with a casual attitude towards software piracy. Mr. Glath described shareware and freeware as good marketing approaches but warned that there are some nasty people who modify good programs, making harmful copies of them. A virus, as defined by Mr. Glath, is "a nasty" that replicates itself. But whether the nasty program is a virus or a Trojan Horse, it all boils down to computer sabotage. He outlined the types of nasty programs- - MASSIVE DESTRUCTIVE which destroy the whole computer system. - PARTIAL DESTRUCTIVE which may attack the File Allocation Table (FAT) or the boot sector of a hard disk. - SELECTIVE ATTACK which attacks specific files (eg.; COMMAND.COM or .EXE files.) - RANDOM ATTACK which are elusive. They have no easily discerned mode of attack and, thus, escape detection for a long time. - NON_DESTRUCTIVE which are annoyances. They usually produce messages or modify disk labels. Mr. Glath closed his presentation by noting that the virus proliferation is a real trend that is getting considerable attention, but one will be quite safe if one takes precautions. DONALD MONTABANA: Mr. Montabana reviewed his experiences with computer viruses at the University of Pennsylvania. Since January 1988, the number of virus incidents had not been severe. On average day, he would get five to seven calls about possible virus attacks; most of them were false alarms. On the University's campus, only 10% or less of the calls are actual virus attacks. Most of the recent cases involve ASHAR, BRAIN, or their variants. These types have been prevalent on several other campus as well. These programs will modify disk volume labels; some of them are quite destructive. They get their names from the names they will put into the volume labels. Mr. Montabana noted that the BRAIN virus will infect only the 360K format disks. Other formats, such as the 720K and 1.44M, are immune to the current version of BRAIN. He noted that BRAIN, unfortunately, can eat away at the FAT and that it resides on the boot sector of a hard disk. Mr. Montabana also described some of the precautions used at the University for "safe computing". Certain of the Local Area Networks (LAN's) are isolated. Their users are restricted in what diskettes they can use on these systems. Even blank, formatted diskettes are off-limits. Only unformatted diskettes are allowed to be brought in; they are formatted on these "clean" computers. The arrogance of some virus writers was noted by Mr. Montabana when he told about the threats by virus writers aimed at Tom Brown, the author of VACCINE for the MacIntosh. The virus writers threaten to unleash nastier programs that will circumvent VACCINE's defenses if Tom Brown continues developing anti- virus programs. He noted that the National Computer Security division of the National Security Agency (NSA) is tracking down the perpetrators, intending to prosecute them. Mr. Montabana, along with the other panelists, hope that the sucessful prosecution of virus writers will deter future virus makers. Also, he forsees specific anti-virus legislation down the line. JOHN HAGMAN: Mr. Hagman explained how he became interested in malicious programs after several "hard cards" (hard disks mounted on a card) crashed within weeks of installation at his office. The disks had their boot sectors wiped out. Although the cause of these crashes is still unknown, the incidents perked his curiousity. PEC asked Mr. Hagman to research available defenses against viruses and other malicious programs. So he looked into the various commercial and non-commercial programs. He commented, "There is no piece of software that is going to be the answer." The most popular of these program protect the operating system by checking it periodically against a backup or by using numeric checksum methods. Others look for direct reads and writes to disks. Besides anti-virus software, Mr. Hagman mentioned several other safeguards. Write-protect one's original DOS diskette. Periodically, re- install the systems files on one's hard disk. Computer installations may consider the policy used by PEC- no unauthorized software on the company's machines. STEVE WEISSMAN: He started his presentation by saying that he himself has not seen a virus and that he is somewhat of a "doubting Thomas". He proceeded to describe his experience as a computer systems administrator for a large company and as one of the sysops for the PACS BBS. In both areas, he has not encountered a virus. Mr. Weissman described several factors that has kept his section of the PACS BBS virus-free. The first safeguard is that PACS gets its public domain/shareware software from large software distributors which, for their own protection, check the software. Second, the PAC BBS is a closed BBS; only PACS members can get access. Each uploaded file can be traced back to the person who uploaded it. During the seminar, Mr. Weissman emphasized, "Backup. Backup. Backup," ones data. Regarding the future of the viruses, he said that he does not know but he hopes that well-publicized prosecutions will stop the trend. PAM KANE: The two represenatives from Panda Systems covered separate aspects of the virus problems. Ms. Kane dealt with them from the human resources aspect while Mr. Hopkins covered the technical aspects. Ms. Kane expressed her concern that "BBS's and shareware are getting the image of being the 'public baths' of the computer world." She admonished computerists not to panic but, rather, to take wise precautions. Comparing the viruses to the AIDS situation, she advised that if one is "monogamous" with one's computer, one will be quite safe. She also noted that main mode of virus infection is through innocent spreading by people who are unaware of the viruses. Two of the most prominant categories of innocent carriers are 1) the people who take computer work home with them, and 2) the people who do not have a computer at home and are using their office computers for computer course homework. Both of these categories represent some of the most valuable workers in a corporation. Ms. Kane mentioned some of the precautions to prevent virus spread. One of these methods is to boot from floppy when preparing to call a BBS to download files. The files should be downloaded to a floppy, not to the hard disk. If one does get a virus, remember to use low-level format when cleaning up the hard disk. She emphasized the importance of keeping aware of the files on one's hard disk- "Be in touch with your hard drive." ANDY HOPKINS: Mr. Hopkins told how the popular Trojan Horse and virus detctor programs CHK4BOMB and BOMBSQAD were both unauthorized releases of software developed by Panda Systems. Some versions of these programs, he warns, have been modified and made into destructive programs. He explained how the Doctor Panda Utilities ultilize the methods similar to the two programs, but with additional features. The Utilities have a three-part approach- - PHYSICAL which creates a "clean model" of the computer system and uses the "model" to check for abnormal alterations of systems files and any other files specified by the user. - LABTEST which reads a specified file, checks for commands bypassing DOS, and displays any embedded ASCII characters. - MONITOR which loads into the memory and monitors for specified types of disk activity, stopping the system if any are encountered. CONCLUSION From the presentations and the discussions, one could glean much information about computer viruses. While the speakers agreed that nobody can be sure about the future, they agreed that computerists are reasonably safe if they take reasonable precautions. The seminar was well worth the time and effort to get there. As I am writing the finish to this article, I am reminded of a concern expressed by many of the panelists. They were alarmed by the irresponsible computer journalists who have gone beyond informing the public about the viruses by giving "how-to" guides for writing viruses. It is a phenomenon that is especially prevalent in the MacIntosh field. (Perhaps because it appears to be easier to write a MacIntosh virus than a MSDOS one.) This is valid one, since it is important to inform computerists but there is no need to give aspiring virus writers their start. ------------------------------------------------------------------------ = Kenneth R. van Wyk = _ /| = = User Services Senior Consultant = Ack Thippfft! \'o.O` = = Lehigh University Computing Center = =(___)= = = Internet: <LUKEN@VAX1.CC.LEHIGH.EDU> = U = = BITNET: <LUKEN@LEHIIBM1> = Bill 'n Opus in '88! = ------------------------------------------------------------------------ ========================================================================= Date: Fri, 6 May 88 08:24:05 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Jim Frost <madd@bu-it.BU.EDU> Subject: Re: The Shockwave Rider. |As a "literary" note on viruses [...] Intrepid readers might like the book "P1" which is probably the first book dealing withh the topic ofviruses/worms. I've also read "Valentina" but the former is much better. Now back to your regularly scheduled virus reports.... jim frost madd@bu-it.bu.edu ========================================================================= Date: Fri, 6 May 88 08:32:11 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Jim Frost <madd@bu-it.BU.EDU> Subject: Re: Virus Construction Set |bad news from Germany. I have forgotten to tell you something in my |last message: Not all people concerned with computer viruses (esp. |virus programmers) over here are aware of what they are doing. In April |this year a unbelievable program called "VIRUS CONSTRUCTION SET (VCS)" |was released at the Hannover computer faire CeBIT. I don't know about in Germany, but it's my bet that anyone releasing such a beast in the United States would get a handful of lawsuits. I'd be in on sueing the hell out of them! What would prompt someone to write such a damaging "utility"? jim frost madd@bu-it.bu.edu ========================================================================= Date: Fri, 6 May 88 09:37:19 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1> Subject: files A couple people have made some great suggestions for improving the uuencoding/uudecoding process here on VIRUS-L. So, I've included a BASIC version of uudecode (filename UUDECODE BAS) as well as a new improved uuencode/uudecode package called uu213 (filename UU213 UUE). The BASIC uudecoder will work with any GW-BASIC compatible BASIC interpreter...slowly. It is *not* ...er...shall I say, fast. But, for those of you who don't have Turbo Pascal, you can get the BASIC uudecoder, and the UU213 package. UU213, by the way, is a uuencoded ARC file containing a very fast uuencode and uudecode in executable form. Both of these files were obtained from the MS-DOS archives on SIMTEL20.ARPA. Thanks to all who sent in these suggestions and files! Hopefully, this will be the uuencode/uudecode to end all uuencode/uudecode's. :-) Ken ------------------------------------------------------------------------ = Kenneth R. van Wyk = _ /| = = User Services Senior Consultant = Ack Thippfft! \'o.O` = = Lehigh University Computing Center = =(___)= = = Internet: <LUKEN@VAX1.CC.LEHIGH.EDU> = U = = BITNET: <LUKEN@LEHIIBM1> = Bill 'n Opus in '88! = ------------------------------------------------------------------------ ========================================================================= Date: Fri, 6 May 88 14:12:40 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: OJA@NCCIBM1 One of the things mentioned in the discussions during the La Salle virus seminar was the existence of malicious program that would rewrite or erase firmware but rapid reads and writes which would heat up the EPROMs and erase them. I haven't heard of this before so I am putting out for comments, etc. The only form of hardward damage from a malicious program that I know of is an old Trojan Horse for the early Commodore PETs. It would burn out their monitors if allowed to run for a while. Just a quirk of the beastie. J. D. Abolins ========================================================================= Date: Fri, 6 May 88 13:59:00 EST Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Mitchel Ludwig <KMFLUDW@VAX1.CC.LEHIGH.EDU> Subject: RE: Re: Virus Construction Set >|bad news from Germany. I have forgotten to tell you something in my >|last message: Not all people concerned with computer viruses (esp. >|virus programmers) over here are aware of what they are doing. In April >|this year a unbelievable program called "VIRUS CONSTRUCTION SET (VCS)" >|was released at the Hannover computer faire CeBIT. > >I don't know about in Germany, but it's my bet that anyone releasing >such a beast in the United States would get a handful of lawsuits. >I'd be in on sueing the hell out of them! > >What would prompt someone to write such a damaging "utility"? Jim, Not that you (or anyone for that matter) will want to hear this, but chances are good that anyone wishing to market such a program in the U.S. will have no problem doing so. It's probably comparable to those selling the copy boards and such which would seem to be in direct violation of the shrink wrap laws (are those the correct laws?) Unfortunately, as I see it, the free speech laws (of the press... etc) allow such programs to be sold... We don't have to like it... But we do have to deal with it... Mitch Tag... You're it ____________ ____/--\____ //-n-\\ \______ ___) ( _ ____) _____---=======---_____ __\ \____/ / `--' ====____\ /.. ..\ /____==== ) `|=(- - - - - - - - - - -*// ---\__O__/--- \\ \------------' \_\ /_/ BITnet : MFL1@lehigh.bitnet Phonet : 215-758-1381 INTnet : KMFLUDW@vax1.cc.lehigh.edu Slonet : Box 72 Lehigh Univ. Bethlehem, PA 18015 ========================================================================= Date: Fri, 6 May 88 13:30:00 CDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: GREENY <MISS026@ECNCDC> Subject: re: hardware damage > The only form of hardward [sic] damage from a malicious program that I know of > is an old Trojan Horse for the early Commodore PETs... Hmmm....I seem to remember a program for the Commodore VIC 20's that would fry out a ROM or two. Also the old tale from the days of core memory, of a nutty programmer that continually accessed a location in memory until the core that represented this memory location heated up. The core was directly over an overheat sensor. When the core got hot enuf, the sensor tripped, and the machine shut down. Good thing we don't use core memory anymore! Bye for now but not for long... Greeny Bitnet: MISS026@ECNCDC Internet: MISS026%ECNCDC.BITNET@CUNYVM.CUNY.EDU Disclaimer: What?? Who? Me? Nope...not me! It's that guy over there! ========================================================================= Date: Fri, 6 May 88 14:28:03 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Jim Frost <madd@bu-it.BU.EDU> Subject: Re: |The only form of hardward damage from a malicious program that I know of | is an old Trojan Horse for the early Commodore PETs. It would burn out |their monitors if allowed to run for a while. Another such problem exists with the old monochrome boards for PC's. I haven't heard of any trojan horses/viruses which take advantage of it, but it exists. jim ========================================================================= Date: Fri, 6 May 88 14:39:22 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Jim Frost <madd@bu-it.BU.EDU> Subject: RE: Re: Virus Construction Set |>What would prompt someone to write such a damaging "utility"? | Not that you (or anyone for that matter) will want to hear |this, but chances are good that anyone wishing to market such a |program in the U.S. will have no problem doing so. It's probably |comparable to those selling the copy boards and such which would seem |to be in direct violation of the shrink wrap laws (are those the |correct laws?) It's not the same thing. You have a right to archive programs for your own use, which is why the copy people haven't been knocked out of business. Copying something does no harm to another person, unless it's illegal copying and there are laws against that. A virus can (is supposed to?) cause harm. The question isn't whether or not someone can be sued for it, but rather who gets sued. Should it be the person that sent out the virus, or should it be the company that made the virus creation program? In any case, the company has aided in the crime and may be at fault (although it might be possible to use a "people kill with guns but gun companies aren't held responsible" argument to get around this). I guess we'll never know until it happens. jim ========================================================================= Date: Fri, 6 May 88 14:52:38 edt Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Travis Lee Winfrey <travis@madonna.columbia.edu> In-Reply-To: OJA%NCCIBM1.BITNET@cuvma.columbia.edu's message of Fri, 6 May 88 14:12:40 EDT <8805061822.AA00632@columbia.edu> Hi all; I'm new to this list. A few questions which may have been answered before: Is there a list anywhere of known viruses, malicious or otherwise? or of hardware/software combinations for which virus programs exist? Also, is there a list of antibody- and immunization-type programs, including those like chk4bomb that have been tampered with and re-released? it would be useful to have checksums published with these programs, although I suppose a virus writer wouldn't be too troubled to make a checksum balance out. perhaps multiple checksums could be used to foil simple padding. based on what has been discovered so far, does anyone have any feel for the percentages of malicious vs. nonmalicious/humorous/political viruses out there? can anyone recommend a beginning text on epidemiological analysis? :-), but I would really be interested in such a book. t ========================================================================= Date: Fri, 6 May 88 14:56:50 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1> In-Reply-To: Message of Fri, 6 May 88 14:52:38 edt from <travis@madonna.columbia.edu> >Is there a list anywhere of known viruses, malicious or otherwise? or of >hardware/software combinations for which virus programs exist? Wouldn't be too bad to start with DIRTY DOZEN, available here on VIRUS-L. It seems to be *reasonably* thorough. If you don't know how to get files from here, e-mail me directly and I'll let you know. Ken ------------------------------------------------------------------------ = Kenneth R. van Wyk = _ /| = = User Services Senior Consultant = Ack Thippfft! \'o.O` = = Lehigh University Computing Center = =(___)= = = Internet: <LUKEN@VAX1.CC.LEHIGH.EDU> = U = = BITNET: <LUKEN@LEHIIBM1> = Bill 'n Opus in '88! = ------------------------------------------------------------------------ ========================================================================= Date: Fri, 6 May 88 13:10:00 CST Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: LOWEY@SASK Subject: How can we protect programs from viruses? Hi, I have written a number of utilities and programs which I put into the public domain. Usually they are written in Turbo Pascal, and the source code is distributed as well. One thought I had was include a CRC check in the program. Randomly throughout the code, the program would do a CRC check on its .EXE or .COM file (or optionally the executing image). If it didn't pass the test, then it would display a message that the program was tampered with and exit. I think Lotus 1-2-3 does this as part of its copy protection scheme. If something like this was added to the MS-DOS utilities and public domain programs, it could stop the spread of some viruses. For instance, if COMMAND.COM had such a check, it would be much harder for a hacker to patch a virus into it. Does anyone know of any method that protects your programs even if the hacker knows the method used to do the protection? In otherwords, a hacker can know how it was done, but not how to defeat it? Thanks, Kevin Lowey -- University of Saskatchewan Computing Services ========================================================================= Date: Fri, 6 May 88 19:38:00 MDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> Comments: Warning -- original Sender: tag was KPETERSEN@SIMTEL20.ARPA From: Keith Petersen <W8SDZ@SIMTEL20.ARPA> Subject: Flushot-Plus version 1.2 now available from SIMTEL20 The latest version of FLUSHOT, the anti-Virus/anti-Trojan program for MSDOS, is available via standard anonymous FTP from SIMTEL20 as... Filename Type Bytes CRC Directory PD1:<MSDOS.TROJAN-PRO> FSP_12.ARC.1 BINARY 45646 2AD5H This is Flushot-Plus, version 1.2. It was obtained directly from the author, Ross Greenberg, to assure its validity. --Keith Petersen Maintainer of the MSDOS archives at SIMTEL20.ARPA ========================================================================= Date: Mon, 9 May 88 16:05:00 CET Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Karl-L. Noell" <NOELL@DWIFH1> Subject: hunting up infected files Now we have come to the point where it's even possible to infect files without altering their size or their time date stamps. So I'd like to recall the well known, efficient and approved cyclic redundancy check (CRC). It should be good practice, to compute the CRC remainder every week for all files on harddisk drives. For this purpose I'm using the very helpful tool FILECRC written by Ted H. Emigh. It's in SIMTEL20 / RPICICGE <MSDOS.FILUTL>FILECRC.ARC . Running FILECRC computes the individual checksums and leads over to compare them with the CRCs obtained from the previous run. This will uncover all files which have been altered since the last run, especially those modified in a 'non-DOS-manner'. And all *new* files are shown, revealing unwanted descendants born by trojanic creatures or hatched out of any cuckoo egg. Karl Noell fhw (Wiesbaden, W.Germany) ========================================================================= Date: Mon, 9 May 88 10:52:00 EST Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Jerry Leichter (LEICHTER-JERRY@CS.YALE.EDU)" <LEICHTER@YALEVMS> Subject: CRC's for detecting viruses Unfortunately, it is very easy to modify a file so that any given CRC remains unaltered. The protection you get by using a CRC is thus quite limited - it stops those virus-writers who aren't clever enough to work around it. Stepping back a bit and looking at the bigger picture: Given a program P, viewed as a bitstring (or a very large number or a polynomial over Z mod 2 or whatever is convenient), we want to compute a signature S(P) which is (a) fairly small; (b) chosen so that it is "highly likely" that, if Q != P, S(Q) != S(P). An example of a simple signature function is "number of bits (bytes, blocks) in P" - the size of the file. This simple function also points out the weak- ness that a given S may have: "Highly likely" must refer to a given set of ways of chosing Q != P. Virus makers at first did not go out of their way to chose Q's the same size as P, so this S worked fine. Now they know better, and this S is useless. There are many other possible S functions: Sum of the bytes of P, XOR of P viewed as a vector of 16-bit words, various weighted sums (given by something like S[0] = 0; S[i+1] = k*S[i] + P[i], where P[i] is the i'th byte/word of P and S = S[size(P)]), and so on. CRC is yet another possibility. All these choices of S have uses given particular ways of chosing Q. CRC is good if Q is what comes out after sending P over a noisy telephone line - the kinds of changes that that process induces to form Q from P are "highly likely" (in a very precise sense) to change the CRC. However, when you are talking about a change due to an intelligent opponent, the story is very different. There exist "cryptographically strong" S functions, in the sense that, given P and S(P), it is "very difficult" - as hard as breaking some code - to find ANY Q != P with S(Q) = S(P). DES, the Data Encryption Standard, provides a mode of use, called CKS (checksum) mode, in which you chose a secret key K, then compute S(P) = DES_CKS(P,K). This is cryptographically strong - it is as hard to break as DES itself. Unfortunately, it requires that K be kept secret - given K, it is no more secure than, say, XOR. What this means is that an individual can chose a secret K and use this technique to checksum his own files - but there is no way to publish a list of (P,S(P)) values that would do anyone any good in determining whether a program they received was intact, since to test it they would need to know K - and then the bad guys would know K, too. DES requires fairly slow computation. It turns out that CRC CAN be used this way, if you chose a random, secret CRC polynomial. There's a paper by Michael Rabin called "Fingerprinting by Random Polynomials" - sorry, I don't have a handy reference - that shows how to do this, and proves that the result is cryptographically strong - as long as the polynomial is kept secret. It is also possible to construct cryptographically strong signatures that do NOT require that a secret be kept. These are essentially one-way functions that are thought, for good reason, to be hard to invert. It isn't hard to build one of these using DES, or any good encryption function. Unfortunately, they tend to require a LOT of slow computation - what happens is that pieces of P get fed in to the encryption function, not as data, but as keys. Encryption algorithms are designed for reasonable implementation for a FIXED key and VARIABLE data - changing the key all the time is hard, since fast implementa- tions usually rely on munging on the key for a while to set things up just right. (BTW, the security of such schemes comes from the difficulty, in a good encryption system, of learning the key, even given a lot of plaintext/ ciphertext pairs.) I would suggest a compromise: A mechanism that, while not completely secure, makes things very hard on a virus-maker while not requiring huge amounts of computation. When a program is published, a large number of random polynomials (say, 100 or 1000) are chosen, using the techniques of Rabin's paper. The CRC of the program with ALL the polynomials is published. To check a program, you chose any two of the polynomials - also published - compute the CRC's, and compare. (You must, of course, chose those two at random.) The virus maker must make his program have the same CRC with respect to ALL the 100 or 1000 polynomials - which is possible, but requires (I believe, this would need to be studied) a LOT of computation. (The length should probably be checked - it's going to be a lot easier on the virus maker if he can add extra stuff to the end of the program to make the CRC's come out right.) -- Jerry ========================================================================= Date: Mon, 9 May 88 12:50:00 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Atul Butte <ST602397@BROWNVM> Subject: Preventing public domain software contamination With all the problems with virus infected public domain and shareware software, I propose the following solution (for the Macintosh): There exists a shareware program called StuffIt 1.4 which was designed to group multiple files into one file which can then be uploaded. StuffIt 1.4 is for the Macintosh, and is turning into a sort of standard for packing. StuffIt 1.4, in addition to grouping files can compress them and can encrypt them. The proposal: How about adding a new feature to StuffIt that encrypts files, but in such a way that they can only be decrypted and not encrypted again? This can be done with the following method. StuffIt could prompt the uploading user to enter an encrypting code which is used to encrypt the files. Along with the files, another code is included. This code is the decrypting code, which downloading users can use to decrypt the file. The decrypting code could be hashed by some secret function into the original encrypting code. This method is similar to the "trapdoor" functions used for Public-Key Cryptosystems with one-way functions. The advantage of this is that the original author of a program can encrypt his or her software and place it in the public domain without the fear of others downloading the file, contaminating it with a virus, and then uploading the file as the original. Atul Butte /----------\ /----------\ Brown University ! OK ! ! CANCEL ! ST602397@BROWNVM.BITNET \----------/ \----------/ ========================================================================= Date: Mon, 9 May 88 13:31:33 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1> Subject: file confusion There appears to be quite some confusion as to how to get files from the VIRUS-L archives - I've gotten a *lot* of requests to better explain myself. Everyone on this list subscribed to the list by sending a message to LISTSERV@LEHIIBM1 stating SUB VIRUS-L your name. Well, retrieving files is very similar to this. Specifically, you will once again be sending a message to LISTSERV@LEHIIBM1, but instead of SUBscribing, you will be GETting a specific file. So, to get a particular file, like DIRTY DOZEN, send mail to LISTSERV@LEHIIBM1 containing: GET DIRTY DOZEN VIRUS-L That's all. You'll get the file DIRTY DOZEN in your mail shortly afterwards. If you want to *see* what files are available, send INDEX VIRUS-L Also to LISTSERV@LEHIIBM1. Care should be taken to *NOT* send the message to VIRUS-L@LEHIIBM1 since it will go out to the entire list and not reflect favorably upon yourself... :-) Hope this clears things up. Sorry for the repetition to those who already know all about this. Ken ------------------------------------------------------------------------ = Kenneth R. van Wyk = _ /| = = User Services Senior Consultant = Ack Thippfft! \'o.O` = = Lehigh University Computing Center = =(___)= = = Internet: <LUKEN@VAX1.CC.LEHIGH.EDU> = U = = BITNET: <LUKEN@LEHIIBM1> = Bill 'n Opus in '88! = ------------------------------------------------------------------------ ========================================================================= Date: Mon, 9 May 88 17:19:52 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Jim <15360JIM@MSU> Subject: Request FSP_12.ARC.1 (Newest Flushot-Plus Program) I tried to get a lastest copy of fsp_12.arc.1 I read a message that I can get a clear copy from simtel20.arpa. But I don't know how to access to simtel20.arpa directly. By the way, I checked listserv at rpicicge and couldn't find any fsp_12.arc.1 there. Please help me out! ========================================================================= Date: Mon, 9 May 88 17:30:34 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: OJA@NCCIBM1 In-Reply-To: Travis Lee Winfrey's message of 6 May 88 Regarding the inquiry of a list of known viruses, malicious, or otherwise.... first check the dirty dozen listing available as a file from VIRUS-L. In a few weeks or earlier, I can get a quick amalgam of couple of articles listing many of the viruses. In a month or so, I hope to make a "VIRLOG" patterned after the "dirty dozen" listings. It will be helpful but I can't gaurantee it will 100% comprehensive. But I will be seeking to compile whatever info I get here, from RISKS, and elsewhere that can be published. With that listing will be a list of anti-virus/bomb programs. BOMBSQAD and CHK4BOMB have been mentioned. On the files areas, there are several good programs. As for tampered programs, well... it is hard to keep up with that. However, I can warn you about FLUSHOT4. It is a tampered version; that is why Ross Greenberg calls his program FLUSHOT+ or (FSP). But the DOS REName command makes tracking these nasties impossible. Whatever the name of the FLUSHOT type program, watch for ones with executable text files (ie.; COM or EXE files to run so the documentation will be displayed.) Ross Greenberg uses ASCII files for the documentation. Other than that and the suspect NOTROJ program (another story in itself), I don't know of other tampered "cures". Regarding books, I have heard of a "Hacker's Manual" but I haven't seen it. There is no major book yet that I know of which deals specifically and in detail about malicious programs. J.D. Abolins ========================================================================= Date: Mon, 9 May 88 18:25:27 edt Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Travis Lee Winfrey <travis@madonna.columbia.edu> In-Reply-To: OJA%NCCIBM1.BITNET@cuvma.columbia.edu's message of Mon, 9 May 88 17:30:34 EDT <8805092142.AA17475@columbia.edu> Regarding books, I have heard of a "Hacker's Manual" but I haven't seen it. There is no major book yet that I know of which deals specifically and in detail about malicious programs. yes, I've seen the hacker's manual at a bookstore nearby. it pre-dates viruses, and is more for breaking into computers over networks or dialup lines. it was surprisingly accurate, listing for each os: the login procedure, how to find out user ids, what the privileged ids are (root, system, operator). I didn't see any lists of security bugs, but I was just glancing through it. there was also a lot of phone-phreaking information in it. the techniques are mostly for game-seeking kids playing around with modems, but they do good job of stripping away any security-by-ignorance schemes. t ========================================================================= Date: Mon, 9 May 88 15:40:00 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Joseph M. Beckman" <Beckman@DOCKMASTER.ARPA> Subject: Re: hunting up infected files In-Reply-To: Message of 9 May 88 11:05 EDT from "Karl-L. Noell" As an employee of the National Computer Security Center, I must point out that we do *NOT* attempt to track perpetrators for prosecution or for *ANY* other reason! We are not a law enforcement Agency, and are prohibited by law to take any such action. We are interested in tracking the viruses (or ordinary Trojan Horses) as they infect different sites. As a matter of professional interest, I would be curious as to the motivations of perpetrators of malicious code, or whether they are members of "Hacker Clubs;" but that is information that may be conveyed without identifying the people/organizations involved. Joseph ========================================================================= Date: Tue, 10 May 88 11:35:32 edt Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Travis Lee Winfrey <travis@madonna.columbia.edu> From: LOWEY%SASK.BITNET@cuvma.columbia.edu Subject: How can we protect programs from viruses? If something like this was added to the MS-DOS utilities and public domain programs, it could stop the spread of some viruses. For instance, if COMMAND.COM had such a check, it would be much harder for a hacker to patch a virus into it. yes, but as with all checks built in to programs, if the test(s) can be found in the code, executable or source, it can be patched and circumvented. however, such checks would be very useful in slowing the spread of a virus. t ========================================================================= Date: Tue, 10 May 88 17:41:00 LCL Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Michael Wagner new! +49 228 8199645 <WAGNER@DBNGMD21> Subject: Re: Virus Construction Set > I don't know about in Germany, but it's my bet that anyone > releasing such a beast in the United States would get a handful of > lawsuits. I'd be in on sueing the hell out of them! You'd have a hard time even finding a ground. The fact that a crowbar can be used for burglary doesn't make it illegal to make crowbars. Similarly, selling copy protection defeaters isn't illegal nor key making machines. So it isn't per se illegal In terms of suing, you'd have to show that the manufacturer made something so unsafe that the owner of the program could not handle it safely. I don't know how you'd go about doing that. So suing the manufacturer is likely to be unprofitable. There are certain tools, the mere possession of which is a crime. The law justifies this by saying that there is no legitimate use for the tool, only the illegal one. However, I think these must be explicitely listed, and I bet virus makers aren't on the list Perhaps you could them added. Michael ========================================================================= Date: Tue, 10 May 88 17:19:00 LCL Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Michael Wagner new! +49 228 8199645 <WAGNER@DBNGMD21> Subject: Re: Virus Construction Set > bad news from Germany. ... In April this year a unbelievable > program called "VIRUS CONSTRUCTION SET (VCS)" was released at the > Hannover computer faire CeBIT. Actually, at least on a certain philosophical plane, I see this as a good thing. I have grown sick and tired of hearing, for most of the past decade, that security exposures are 'no problem' because no one except a real expert will be able to find them, let alone exploit them. "No one will discover that back door and so we are safe". This innocent, cute approach to a real problem is really a disservice to the community. Babies are innocent and naive. They start out their lives shoving anything that fits in their mouth into their mouth. They have to be taught to only put food into their mouths, and to accept food only from trustable sources. If not, they can get very sick, and perhaps die. Basically, for the last few years, we computer people been living in a dream world. It seems that we, as adults, still have to learn that, just because something fits, you don't *have* to try sticking it in (we can skip the obvious sexual parallels) and doing so might just be dangerous. If VCS does nothing else, it will demonstrate: > You dont have no know how a virus work to create one, you just > have to know how to turn on your Atari and how to start the VCS > program!!! Maybe, as a result, manufacturers (hardware and software) will no longer be able to rely on the principle that complexity and secrecy are adequate protection. When the consumer population understands the implications of 'toys' like VCS, even little kids will laugh at manufacturers who are silly enough to continue to tell their consumers such nonsense. Michael ========================================================================= Date: Tue, 10 May 88 12:47:26 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Jim Frost <madd@bu-it.BU.EDU> Subject: software self-checks | If something like [a self-integrity check] was added to the | MS-DOS utilities and public domain programs, it could stop the | spread of some viruses. For instance, if COMMAND.COM had such a | check, it would be much harder for a hacker to patch a virus into | it. | |yes, but as with all checks built in to programs, if the test(s) can be found |in the code, executable or source, it can be patched and circumvented. |however, such checks would be very useful in slowing the spread of a virus. A couple of comments to this. Yes, it'd slow the spread of viruses, but it would also make you less paranoid about them (and thus less likely to catch them), make viruses more likely to be obnoxious (what kind of person would spend the time to work around the protections?), and slow the system down as well. This is a classic argument about security. The advent of a "secure" system will make users forget about security. When security is breached, the breach may never be found because no one is looking for it. Also, a word about intermittent security. Users of the PClone utility FLUSHOT (or its relatives) should be aware that just because a program doesn't do anything while you're running with protection doesn't mean it won't while you're not. It is trivial to add code to check to see if the FLUSHOT program is resident in your machine and just sit there if it is, but wreck things if it is not. Just when you trust a program enough to not use the protection, you'll get burned. jim frost madd@bu-it.bu.edu ========================================================================= Date: Tue, 10 May 88 13:32:08 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1> Subject: Checkup available on VIRUS-L The Checkup program is now available on VIRUS-L. It is a shareware checksum program to aid in determining whether or not a file (or files) has been altered. The filename is CHKUP14 UUE. It's a uuencoded ARC file. A caveat on this program, as with all the programs on VIRUS-L - they're public domain (or shareware), and you get what you pay for. ...which isn't to say that they're without merit. I have run all of the programs that I've posted, and I have obtained them from reliable sources (SIMTEL20.ARPA for the most part). Regards, Ken ------------------------------------------------------------------------ = Kenneth R. van Wyk = _ /| = = User Services Senior Consultant = Ack Thippfft! \'o.O` = = Lehigh University Computing Center = =(___)= = = Internet: <LUKEN@VAX1.CC.LEHIGH.EDU> = U = = BITNET: <LUKEN@LEHIIBM1> = Bill 'n Opus in '88! = ------------------------------------------------------------------------ ========================================================================= Date: Wed, 11 May 88 09:48:55 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1> Subject: christmas exec details Here are some details about the IBM "Christmas Exec" virus that was floating around the network world right around Christmas 1987. These were forwarded to me by a reader: Date: 10 May 1988, 13:09:54 +0200 (MESZ) From: Otto Stolz +49 7531 88 2645 RZOTTO at DKNKURZ1 Subject: DIRTY DOZEN (Issue #8: February 21, 1988) > ????????.??? ?????? V There is a virus that was circulating > around Bitnet in December that advertises I can give you some details on this network-virus: It's name was CHRISTMA EXEC . I forgot its file size, and have kept no log of it. It consisted of a single program in the REXX language, which has been available in the VM/SP operating system (for IBM mainframes) since Release 3. (The REXX language is also available under MS-DOS for IBM-PC, -XT, and -AT, and it is announced for the mainframe operating system MVS/TSO-E; but for reasons given below, I reckon the virus could reproduce itself only under VM/SP.) The source of CHRISTMA EXEC (with REXX, there isn't anything as an object code file) started with a lore of say-instructions, that apparently would display a sketch of a Christmas-tree together with some good wishes on the screen. This bunch of (in fact rather boring) statements filled one and a half screens; it was followed by a half-screen-sized comment, stating roughly "Reading source-code like this is boring, rather RECEIVE this program, and just enter CHRISTMA" (the latter CMS command would have started the program). When you actually started the thing (I didn't do it, but people told me), the program indeed displayed a Christmas-Tree and best wishes for the year to come. Then it read two files, CMS (part of VM/SP) maintains on behalf of every user. The first one is called <userid> NETLOG, and contains a log of network traffic the user has been involved in. Here is a sample entry of my personal RZOTTO NETLOG file ("disc" meaning "discarded", and "from" pointing to the sender's address): File CHRISTMA EXEC A1 disc from RZBERAT1 at DKNKURZ1 on 12/16/87 14:34:44 sent as CHRISTMA EXEC A1 The NETLOG file contains similar entries for notes and files having been sent by the respective user (me, in the example). The second one is called <userid> NAMES and contains sort of private directory of people you are in correspondence with. Here are four sample entries of my private RZOTTO NAMES file: :nick.VIRUS-L :userid.VIRUS-L :node.LEHIIBM1 :notebook.VIRUS-L :name.Virus Discussion List :nick.VIRUS :name. Owners of VIRUS-L :notebook. VIRUS-L :list. KenVWyk Eshleman :nick.KenVWyk :userid.LUKEN :node.LEHIIBM1 :name.Ken Van Wyk :nick.Eshleman :userid.LUJCE :node.LEHIIBM1 :name.Jim Eshleman CHRISMA EXEC extracted all network addresses from these two files, and sent a copy of itself to every of these addresses except the address, from where it came to the current user (thus avoiding the ping-pong effect). The poor victim's very next experience: he received replies from thousands of BITNET nodes, telling him where the hundreds of CHRISTMA copies went. At last, CHRISTMA EXEC destroyed its own source on the user's disk. As CHRISTMA EXEC relied on one of the two special CMS files, it probably could reproduce itself only in VM/SP systems (I don't know, how net- working is implemented under TSO or under MS-DOS). Furthermore, it depended on active help of the user being "infected" to reproduce itself: he had to enter two commands, RECEIVE and CHRISTMA. This active help was provoked by an appeal on peoples curiousity and playfulness. In spite of these two handicaps, CHRISTMA EXEC spread within two days, worldwide. The effect was enhanced, as some copies went to BITNET discussion lists, where they automatically were duplicated and distribu- ted as any sensible contribution will be. If I remember correctly (and if I can trust rumours), it originated (as a student's joke) somewhere in Germany, went through USA, and came back to our blessed country from the far east. It's severest effect was obstructing the whole network with thousands of copies of itself. The cure was very simple: every node had to run a quickly developped program that purged every file of name CHRISTMA EXEC from the node's spooling area, the only difficulty being the distribution of this "macrophage" program through the helplessly overloaded network. Even without this cure, CHRISTMA would probably be extinct by now, as any user seeing it for the second time would have discarded the file, remembering the traumatic experience of the first time, when he started that thing. Thus by now, BITNET is probably "immune" to this virus. The moral of the story: 1. read and understand programs you receive without having asked for, before you run them. 2. Think about the possible results before starting a practical joke. Best regards Otto. ------------------------------------------------------------------------ = Kenneth R. van Wyk = = = User Services Senior Consultant = Badgers! We don't need = = Lehigh University Computing Center = no stinkin badgers! = = Internet: <LUKEN@VAX1.CC.LEHIGH.EDU> = = = BITNET: <LUKEN@LEHIIBM1> = = ------------------------------------------------------------------------ ========================================================================= Date: Wed, 11 May 88 10:25:27 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "David A. Bader" <DAB3@LEHIGH> I have a question dealing with PKX35A35 and a virus/trojan associated with it. In the issue #8A of the Dirty Dozen by Eric Newhouse (available from this list) dated 2-21-88, Eric writes "As of this writing, Phil Katz (author of PKXARC) has verified that version 35A35 is the latest version of his ARChive extractor. This phony PKXARC scrambles FAT tables." (Refering to a suspected Trojan Horse: PKX35B35.EXE) Anyway, through local BBS's, I attained a BugFix archive called PK35BUG, complete with documentation supposedly written by Phil Katz, that supposedly fixes a bug in PKX35A35.EXE for "large binary files." The files in this archive are dated 9-22-87 through 9-27-87. I have heard through the grapevine that this BugFix will spread a virus, through archives, and also that it is legitimate, but still, no one has given me a consistent answer. I tried to contact Phil Katz through US Mail, Bitnet, and BBS's, but never got a response. Is this BugFix his, or not? (I have a copy of it, if anyone wishes to see it. The fix is about 3K.) Also, why would Phil Katz tell Eric Newhouse that 35A35 is the latest version, if he had released a BugFix, and why would Phil Katz release a BugFix, instead of releasing a whole new version to alleviate these problems? Any comments are welcome! -David Bader ========================================================================= Date: Wed, 11 May 88 09:20:00 CST Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: LOWEY@SASK Subject: PKARC bug, it is a valid patch > I have a question dealing with PKX35A35 and a virus/trojan associated > with it. > Anyway, through local BBS's, I attained a BugFix archive called PK35BUG, > complete with documentation supposedly written by Phil Katz, > that supposedly fixes a bug in PKX35A35.EXE for "large binary files." > The files in this archive are dated 9-22-87 through 9-27-87. There was an official bug fix for PKARC. The problem was that when files were SQUASHED, and started with a certain character (CHR(0) I think) then it would not be unarchived. I tested this and the bug existed. I applied the patch I got from uucp, and the bug disappeared. I have had no problems with trojan horses arising from it. However, this official bug had nothing to do with "large binary files". It is possible someone else has released a different "bug fix" which is in fact a trojan horse. > Also, why would Phil Katz tell Eric Newhouse that 35A35 is the latest > version, if he had released a BugFix, and why would Phil Katz release a > BugFix, instead of releasing a whole new version to alleviate these > problems? The bug it was fixing was very very minor. Perhaps one in 1000 archives would have the problem. I agree that he should have changed the version number, but he didn't. Kevin Lowey -- University of Saskatchewan Computing Services ========================================================================= Date: Wed, 11 May 88 17:39:00 LCL Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Michael Wagner +49 228 8199645 <WAGNER@DBNGMD21> Subject: Re: software self-checks > |however, such checks would be very useful in slowing the spread of a virus. > > A couple of comments to this. Yes, it'd slow the spread of > viruses, but it would also make you less paranoid about them (and > thus less likely to catch them), ---- I assume this should have been MORE likely to catch them? > make viruses more likely to be obnoxious Some people advocate make-shift virus protection, i.e. protection that is only one step ahead of the virus itself, and works by exploiting very particular properties of the virus. When virus protection only stops up one hole of many, it usually serves to produce a virus strain that circumvents the one plugged-up hole. This is what happened when people tried to patch MVT to make it 'more secure'. It was like the little dutch boy putting his finger in one hole in a sponge. The water just went around his 'secure hole'. Not all virus protection need be so make-shift. MVS was built with security as a basic design criteria, and the sponge is considerably less porous. Our experience at the University of Toronto (where I used to work) was that most infiltrations were done as a pasttime, to show that it could be done, and to show off to friends. If you make this too much work, you cut 99% or more of the perpetrators dead in their tracks. This is not to say that MVS is totally secure. Similarly, my house isn't entirely burglarproof. But you do have to have a strong motivation to work hard enough to break in. I don't store enough (in either place) to justify anyone working that hard to break in (and I don't put on airs like I do, either). Otherwise, I would worry. > (what kind of person would spend the time to work around the > protections?), Rather like the gun control arguments, the real criminals will always have guns, whether you attempt to control them or not. However, 99% of the viruses currently circulating are created by idle minds, and not by real criminals. > and slow the system down as well. This is a relatively weak argument. It runs faster with security controls enabled than it does when it isn't running at all. Besides, security that is 'architected in' rather than strapped on later shouldn't cost very much in computing resources. I like human analogies. If you have to unlock the front door to your house before you walk in, it slows you down. Have you tried to optimize your 'house access time' by leaving it unlocked? > This is a classic argument about security. The advent of a > "secure" system will make users forget about security. There is no such thing as a 'secure' system. There are only more and less secure systems. Therefore, a 'more secure' system includes facilities to enable the 'security officer' to check if security has been breached (for most PCs, the owner is also system manager, purchasing agent and security officer. Thats what he bought in to. If he didn't want all that responsibility, he should have bought time on a mainframe where someone else does that work (and it costs more as a result)). > When security is breached, the breach may never be found because > no one is looking for it. If no one was looking, it was a not-at-all secure system. The greatest security system in the world is useless if no one is watching it. > jim frost madd@bu-it.bu.edu Michael Wagner ========================================================================= Date: Wed, 11 May 88 12:51:41 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Adam Lewis <ALEWIS@UTCVM> Subject: Re: software self-checks In-Reply-To: Message of Wed, 11 May 88 17:39:00 LCL from <WAGNER@DBNGMD21> There is a very good point here about making security such that it takes some effort on the part of the author of the virus to break it. This gets rid of the people who do this to "impress" their friends and neighbors. The problem is that the people who do in fact spend the time it takes to break security are going to do it in a fashion that is much more difficult to figure out and are going to be a lot more sophisticated (i.e. no FORMAT C: in your PC's AUTOEXEC.BAT). It strikes me as another application of Murphy's 90-10 law. ------------------------------------------------------------------------ Adam Lewis :It could be worse, it Center of Excellence for Computer Applications: could be Monday. Univ. of TN, Chattanooga : ------------------------------------------------------------------------ ========================================================================= Date: Thu, 12 May 88 09:15:22 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1> Subject: checksum signatures In looking at the documentation for the Checkup program, I see that they're using a form of a checksum to validate whether or not a file has been altered. Now, a smart virus author can easily circumvent a checksum algorithm by adding dummy characters to the file so that the checksum comes out to the same value. The Checkup program, however, maintains that its scheme is impossible to get around by using padding characters since it calculates the checksum of the entire file as well as that of randomly sized blocks within the file. It then stores this data in (I assume) an encrypted format. This raises an interesting question - is it truly possible to write a checksum/crc/whatever algorithm that will be able to figure out whether or not a file has been changed 100% of the time? Let's assume that the signature data has *not* been tampered with in any way. It is no secret that both checksums and crcs can be circumvented rather easily. But, an algorithm which could validate a file with 100% effectiveness could be very worthwhile looking into. Once again, the validity of the signature data itself would have to be insured via encryption and/or read-only isolation. Comments? Can anyone prove or disprove the claims that the author of Checkup makes? Ken ------------------------------------------------------------------------ = Kenneth R. van Wyk = = = User Services Senior Consultant = Badgers! We don't need = = Lehigh University Computing Center = no stinkin badgers! = = Internet: <LUKEN@VAX1.CC.LEHIGH.EDU> = = = BITNET: <LUKEN@LEHIIBM1> = = ------------------------------------------------------------------------ ========================================================================= Date: Thu, 12 May 88 09:36:19 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "David M. Chess" <CHESS@YKTVMV> Subject: checksum signatures Well, there's a very simple argument that suggests that no short (or even medium-sized) checksum or other signature can be 100% effective in detecting changes to files. Consider: files are large objects, thousands of bytes long. Signatures are smaller than that; at most hundreds of bytes long. When you map a large set into a smaller set, there must be cases in which two or more things in the larger set are mapped onto the same thing in the smaller set (that is, the mapping must be many-to-one); this is just the PigeonHole principle. For instance, if you're assigning all files 10,000 bytes or less a 4-byte checksum, there are 256-to-the-9,996 as many different files as there are different checksums. So the "average" checksum will correspond to a very large number of different files. Whenever two different files have the same signature, that signature will not be 100% effective in detecting changes (since it won't detect one of those two files changing into the other). But we've just seen that whenever the signature is smaller than the maximum filesize, at least two different files will have the same signature. So (assuming this rather rough argument holds!) no small signature can be 100% effective. Fortunately, signatures don't *have* to be 100% effective to be helpful against viruses. Viruses operate under certain constraints, and as long as we can make it sufficiently *hard* to "spoof" the signature, in a sufficiently large number of cases, a signature-based scheme will detect a useful fraction of nerfarious file-changes. Something like that. DC Watson Research Center * Disclaimer: I gave up the idea of majoring in Math sometime * around Complex Analysis. None of the above is an * Official Statement of anybody around here. ========================================================================= Date: Wed, 11 May 88 12:30:00 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Joseph M. Beckman" <Beckman@DOCKMASTER.ARPA> Subject: Sueing Cliff Stoll has suggested that people sue perpetrators who hack into machines. He believes that even if these people cannot be prosecuted sucessfully (under criminal law, for whatever reason(s)), it is still a good idea to sue for damages (in civil court). He believes that this would (at a minimum) show people that organizations are serious in going after these people. Anyone care to sue the Pakistani who loosed the "Brain" virus? Joseph ========================================================================= Date: Thu, 12 May 88 09:18:00 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> Comments: Resent-From: "Joseph M. Beckman" <Beckman@DOCKMASTER.ARPA> Comments: Originally-From: "Joseph M. Beckman" <Beckman@DOCKMASTER.ARPA> From: "Joseph M. Beckman" <Beckman@DOCKMASTER.ARPA> Subject: Re: hunting up infected files In-Reply-To: Message of 9 May 1988 11:05 edt from Karl-L. Noell As an employee of the National Computer Security Center, I must point out that we do *NOT* attempt to track perpetrators for prosecution or for *ANY* other reason! We are not a law enforcement Agency, and are prohibited by law to take any such action. We are interested in tracking the viruses (or ordinary Trojan Horses) as they infect different sites. As a matter of professional interest, I would be curious as to the motivations of perpetrators of malicious code, or whether they are members of "Hacker Clubs;" but that is information that may be conveyed without identifying the people/organizations involved. Joseph ========================================================================= Date: Thu, 12 May 88 12:02:24 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "David M. Chess" <CHESS@YKTVMV> I was shooting off my mouth back in January on an internal conference, about how it should be relatively easy to write a program that would detect most simple viruses, and someone said "OK, let's see it". Being lazy, I responded with pseudo-code. I attach (a slightly updated version of) that pseudo-code for the benefit of the community, for comments, etc. The idea is that the system keeps a big "database" file containing various facts about executable objects (their time/date/length, and any other signature-like things one wants to code), and periodically checks the executables against the database, to see what's changed. Of course a change doesn't mean an infection (could be a patch, an update, etc), but it can be a Clue... The following assumes a PC-DOS base, but could be trivially changed for CMS, etc. Build a list of files to be checked (all EXE files, COM files, BAT files, SYS files, or whatever, on whatever disks). Attempt to open "old database" file If open succeeds, read the records describing the files found last time into the OldRecords structure, and mark each item in that structure as "Not Seen Yet". If open fails, alert user that there is no old database, and ask for permission to continue. Continue only if permission is given. Set NoOldDatabase to True. Attempt to open "list of current files to be checked" file If open succeeds, continue. If open fails, abort with error message. For each file listed in "list of current files to be checked" file (begin Ask DOS about the file (int21H, subfn 4Eh). If the file is "special" (COMMAND.COM, IBMBIO.COM, IBMDOS.COM, whatever else seems reasonable), compute a CRC or other signature for the file (patient users with fast machines can treat every file as special, of course). Look the file up in OldRecords. If the file was not listed there, add it, marked as "Seen". Tell the user that it is a new file (unless NoOldDatabase is true). if the file -was- listed there, and the information is not the same as the information we just got from DOS, or if the file is special and the CRC or signature has changed, tell the user that the file has changed (and how), mark the item as "Seen", update the item to reflect the current information (from DOS and the new CRC calculation) and continue. If the file was listed there, and the information there -is- the same as the information we just got, simply mark that item as "Seen", and continue to the next file. end) For each item in the OldRecords structure If the item is marked "Seen", write it out to the "new database" file. If the item is marked "Not Seen Yet", tell the user it is Gone, and do not write it to the "new database" file. So at the end the user has a report of new files, old files that have vanished, and files that the program could tell had been changed. If there are unexpected new files, or unexpected changed files, the user can try to figure out why, which may lead to discovering a virus. This is designed with a hard-disk system in mind (for floppies, you'd have to store something like the diskette label as well, and prompt the user to swap diskettes alot), and could obviously be improved in various ways. It can also be used in various ways; if you're very worried, you can always boot the system from a write-protected "trusted" disk before using it, and keep the checking program and the "datbase" on a diskette that resides in a locked file cabinet except when checking is going on. There is also lots of room for invention in the "CRC or signature" part of the description. The development of hard-to-spoof signatures is an active research area. Now of course (more of courses) there are many possible viruses that this sort of scheme won't catch. But it will catch (in the sense that you'll be told about file modifications that you probably didn't expect) the spread of all the executable-file-based PC-DOS viruses that I know of. DC Watson Research Center ========================================================================= Date: Thu, 12 May 88 09:47:07 PDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: pozzo@CS.UCLA.EDU Subject: Signatures and Checksums Yes it is true that you can not find a checksum that is 100% unique as long as the size of the checksum is smaller than the executable. It is a many-to-one mapping. The trick is to find one that has a small possibility that two different executables will generate the same checksum. How "small" depends on you, your system, your needs, etc. The idea of signing executables for protection from modification is not a new one. Most recently, I invite you to read "An Approach to Containing Computer Viruses" published in a 1987 volume of the IFIPs Computers and Security Journal. -Maria ========================================================================= Date: Thu, 12 May 88 11:49:25 CDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Jeff Balvanz <GR.JLB@ISUMVS> Subject: Is there something funny in the posted CHECKUP? Just got the CHKUP14 UUE from the VIRUS-L LISTSERV, but I have a question: when I run the program with CHECKUP CHECKUP.EXE Flushot+ comes back with the message "Write access being attempted on C:\VACCINES\CHECKUP.EXE." Is CHECKUP supposed to try to write on the executable file that you're reading checksums on? Doesn't make sense to me. . .but I'm not a good programmer. Is there something legitimate or illegitimate in CHECKUP, or has my computer been sitting out in a cold draft too long (i.e., has caught something)? ========================================================================= Date: Thu, 12 May 88 13:48:02 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1> Subject: Re: Is there something funny in the posted CHECKUP? In-Reply-To: Message of Thu, 12 May 88 11:49:25 CDT from <GR.JLB@ISUMVS> >Just got the CHKUP14 UUE from the VIRUS-L LISTSERV, but I have a >question: >Flushot+ comes back with the message "Write access being attempted >on C:\VACCINES\CHECKUP.EXE." Is CHECKUP supposed to try to write on >the executable file that you're reading checksums on? When I try the same thing here, I don't get anything. I also tried it on a write-protected floppy and couldn't duplicate it. It appeared to work fine for me - anyone else have any problems with it? If so, I'll remove it from the archives until I can get a copy directly from the author. Ken ------------------------------------------------------------------------ = Kenneth R. van Wyk = = = User Services Senior Consultant = Badgers! We don't need = = Lehigh University Computing Center = no stinkin badgers! = = Internet: <LUKEN@VAX1.CC.LEHIGH.EDU> = = = BITNET: <LUKEN@LEHIIBM1> = = ------------------------------------------------------------------------ ========================================================================= Date: Thu, 12 May 88 14:12:00 CDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: GREENY <MISS026@ECNCDC> Subject: re: the "database" scheme.... this idea is good, providing of course that a virus writer doesn't find out about your database and infect it as well.... I still believe that the best way to validate the length of the files as being unaltered is to have a good hard copy on a piece of paper locked in a safe that only you have the combination to.....(probably in a secret room in your basement...:-) ), then once a month (or however long it takes you to feel paranoid....) you can check the current length against the lengths on the hardcopy. This may or may not be feasible on systems with a huge amount of files (simtel20....), but it would seem to be such for a small-time user.... bye for now but not for long... Greeny Bitnet: MISS026@ECNCDC Internet: MISS026%ECNCDC.BITNET@CUNYVM.CUNY.EDU ========================================================================= Date: Thu, 12 May 88 14:20:00 CDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: GREENY <MISS026@ECNCDC> Subject: re:re: is there something funny in .... > ...did anyone else have any problems with it? If so, I'll get a copy of > it directly from the author... Seeing as how we have been discussing for some weeks now the topic of viruses and how easy it is to infect programs (especially those that cross thru net-land...) I would think that *NO* programs designed to detect viruses and/or eradicate them should be allowed into the Virus-l archives unless they /it have been obtained from the author of such a program directly... Even if it is a "trusted" friend that you are getting the program from, do you trust his/her/it's friends as well? Remember that trust is transitive and that if you trust me, you inherently have to trust everyone that I trust. Therefore, getting it directly from the author seems to be the best possible route of action. That way, if the program does go haywire, you know exactly who to blame... bye for now but not for long... Greeny Bitnet: MISS026@ECNCDC Internet: MISS026%ECNCDC.BITNET@CUNYVM.CUNY.EDU Disclaimer: I'm just visiting this planet, and everything I do on my planet is absolutely legal, so it must be so here! ========================================================================= Date: Thu, 12 May 88 15:25:18 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "David M. Chess 862-2245" <CHESS@YKTVMV> Subject: The "database" scheme There are lots more "provided"s than that! This is intended just to catch viruses of the kind that I know are actually out there. There are probably dozens of ways around it (some involving altering the database and some not), and it doesn't even try to catch boot-record-altering viruses like the "Brain" (although that would be a small mod...). I just thought it might give some budding anti-virus-programmers a concrete jumping off point. Maria commented that it wasn't a new idea: that's very true, and I don't claim to have invented anything new in the least. This kind of modification-detection scheme seems to be the first thing that good programmers think of when they first hear about viruses. More references to previous work along these lines (or any other lines!) would probably be valuable additions to this list. DC ========================================================================= Date: Fri, 13 May 88 01:55:53 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Joseph Sieczkowski <joes@scarecrow.csee.lehigh.edu> Subject: The neverending chain.... Ok guys...let's face some facts: NO software implemented virus protection scheme can ever be 100% effective against stopping viruses because there always can be a counter virus that attackes the protection program. (ie. Virus "A" attacks system, Vaccine "A" protects system, Virus "B" could attack Vaccine "A", etc...) It is also very important to consider the system on which we're implementing a protection package. A PC by definition is unsecure... Why? (1) You can address real memory, and (2) you can access the I/O ports directly. This compounds the problem. This is not to say we should not write protection programs to try and protect ourselves. There is probably much merit in the idea that if a protection scheme is "hard" to break, people might not bother trying. (Let's face it, the "fun" does wear off after days of trying to break protection schemes.) However, we must realize that no scheme is perfectly safe. What we are creating is a "fishnet" to catch most of the viruses around. And, of course, we always have the option of making the net a little finer. Presently, it is of key importance to be aware of these little beasties. (As all of you are as evidenced by being on this list.) In the future, "hardware" protection is probably going to be a neccessity. Hopefully, it won't inhibit system "friendliness" and utility too much. (Remember, the most secure and protected system to date is one which is totally isolated and restricted...and who wants one of those? Yeeek) Joes ========================================================================= Date: Thu, 12 May 88 09:50:00 CST Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: LOWEY@SASK Subject: RE: checksum signatures > This raises an interesting question - is it truly possible to write > a checksum/crc/whatever algorithm that will be able to figure out > whether or not a file has been changed 100% of the time? Of course, one thing you can do is keep copies of sensitive files on other disks, like a floppy disk. You can then use the MS-DOS "comp" or "fc" command (or the unix DIFF or whatever) to see if the files are identical or not. As long as the copy of the file is in a "sterile" environment, where the virus can't get it, this approach should work better than any CRC checks. This doesn't help in my original problem of getting a program to check its self for an infection. Kevin Lowey -- University of Saskatchewan Computing Services ========================================================================= Date: Thu, 12 May 88 09:44:00 CST Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: LOWEY@SASK Subject: RE: checksum signatures > Consider: files are large objects, thousands of bytes long. > Signatures are smaller than that; at most hundreds of bytes > long. When you map a large set into a smaller set, there > must be cases in which two or more things in the larger set > are mapped onto the same thing in the smaller set (that is, > the mapping must be many-to-one); this is just the PigeonHole > principle. Your argument is valid if you just want to corrupt the file. However, as you pointed out, a virus has to work under certain constraints. A virus has to modify a program so it does some damage AND perpetuates its self. Usually the program has to operate correctly for a while to give it time to infect other programs. If we have a CRC checker that not only calculates a CRC, but also saves the original file size, date, and time, then the virus maker would have a tough time. The virus would have to put the damaging code in a specific place in the file (like into the DIR command in COMMAND.COM), with the instructions in a specific order. The virus would have to add code to save the date and time on the file, then reset it back after infecting the file. The virus would have to add more code to make the CRC pass, after determining what CRC was used. Some viruses would need code to see if it is on a hard disk or a floppy disk. A count of how many "infections" would have to be kept to delay the action of the virus. The program would still have to operate "correctly" so the user doesn't know he is infected. All this would have to be done without changing the size or date of the file. So with an appropriate virus checker, it isn't as simple as changing a few bytes to make the CRC work out, assuming you know which CRC was used in the first place. Kevin Lowey -- University of Saskatchewan Computing Services ========================================================================= Date: Fri, 13 May 88 02:36:00 CST Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> Comments: Warning -- RSCS tag indicates an origin of SMTPUSER@SASK From: Derek Andrew <ANDREW@SASK> Subject: RE: checksum signatures It is true that simple checksums are easy to defeat. I suggest considering using the DES algorithm in the following manner. First, consider the file as a sequence of 8 byte blocks (64 bits). Encrypt each block using a public and known password, and add the result to a running total, 64 bits wide. At the end, you have a 64 bit checksum. I doubt anyone reading this is cabable of modifying the original file so as to calculate this checksum. I missed the original posting. I am assuming that the checksum does not reside with the file, but is kept in a seperate location where the virus could not get to it. derek andrew, u of saskatchewan, andrew@sask.USask.ca ========================================================================= Date: Fri, 13 May 88 10:00:53 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Atul Butte <ST602397@BROWNVM> Subject: Preventing Public Domain Software contamination With all the problems with virus infected public domain and shareware software, I propose the following solution (for the Macintosh): There exists a shareware program called StuffIt 1.4 which was designed to group multiple files into one file which can then be uploaded. StuffIt 1.4 is for the Macintosh, and is turning into a sort of standard for packing. StuffIt 1.4, in addition to grouping files can compress them and can encrypt them. The proposal: How about adding a new feature to StuffIt that encrypts files, but in such a way that they can only be decrypted and not encrypted again? This can be done with the following method. StuffIt could prompt the uploading user to enter an encrypting code which is used to encrypt the files. Along with the files, another code is included. This code is the decrypting code, which downloading users can use to decrypt the file. The decrypting code could be hashed by some secret function into the original encrypting code. This method is similar to the "trapdoor" functions used for Public-Key Cryptosystems with one-way functions. The advantage of this is that the original author of a program can encrypt his or her software and place it in the public domain without the fear of others downloading the file, contaminating it with a virus, and then uploading the file as the original. Atul Butte /----------\ /----------\ Brown University ! OK ! ! CANCEL ! ST602397@BROWNVM.BITNET \----------/ \----------/ ========================================================================= Date: Fri, 13 May 88 10:51:35 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1> Subject: Re: Preventing Public Domain Software contamination In-Reply-To: Message of Fri, 13 May 88 10:00:53 EDT from <ST602397@BROWNVM> >How about adding a new feature to StuffIt that encrypts files, but in >such a way that they can only be decrypted and not encrypted again? This >can be done with the following method. StuffIt could prompt the >uploading user to enter an encrypting code which is used to encrypt the >files. Along with the files, another code is included. This code is the >decrypting code, which downloading users can use to decrypt the file. >The decrypting code could be hashed by some secret function into the >original encrypting code. This method is similar to the "trapdoor" >functions used for Public-Key Cryptosystems with one-way functions. Sounds like a fair idea, but what's to prevent a person from un-stuffing all the files, and then re-stuffing them into a brand new stuff file with his/her own encryption code? Sure, only the author could verify the authenticity of the encryption pw, but in the meantime, this new version could be floating all around on different bbs's. Ken ------------------------------------------------------------------------ = Kenneth R. van Wyk = = = User Services Senior Consultant = Badgers! We don't need = = Lehigh University Computing Center = no stinkin badgers! = = Internet: <LUKEN@VAX1.CC.LEHIGH.EDU> = = = BITNET: <LUKEN@LEHIIBM1> = = ------------------------------------------------------------------------ ========================================================================= Date: Fri, 13 May 88 11:39:00 EST Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: GILL@QUCDNAST Subject: Something funny about CheckUp ? I had the same problem with CheckUp occurring that was mentioned earlier. However, I have had a lot of little bugs, system crashes, etc occurring in the last two weeks. My machine is getting a full physical next week, but I think the problem is software oriented. My impression is that FLUSHOT+ is actually buggy. I know for a fact that FLUSHOT+ will crash PCWRITE 2.71 (one can't run PR.EXE from within ED.EXE), and I've had other similar difficulties. I guess that comes from intercepting so many different DOS interupts. Right now, I'm in the middle of a total system backup and reorganization, without FLUSHOT+ to protect/mess me. (However, I may be wrong :-) ) Anyone else had similar, unexplained difficulties? Arnold Gill Queen's University at Kingston gill @ qucdnast.bitnet ========================================================================= Date: Fri, 13 May 88 12:00:04 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "David A. Bader" <DAB3@LEHIGH> Subject: Flushot+'s bugs I, too, had a problem with Flushot+ in that it changed the CMOS memory containing my AT clone's setup information (such as floppy and hard drives connected, time and date, video configuration, system memory, etc.) Also, I recently read that someone had a problem with PCWrite 2.71. To interject a paragraph from Eric Newhouse's Dirty Dozen List Issue #8, revision "A" dated February 21, 1988: PCW271xx.ARC (Suspected Trojan) A modified version of the popular PC-WRITE word processor (v. 2.71) has now scrambled at least 10 FAT tables that I know of. If you want to download version 2.71 of PC-WRITE be very careful! The bogus version can be identified by its size; it uses 98,274 bytes wheras [sic] the good version uses 98,644. For reference, version 2.7 of PC-WRITE occupies 98,242 bytes. David A. Bader Lehigh University ========================================================================= Date: Fri, 13 May 88 08:36:00 LCL Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Communication is the root of insecurity <herbison%ultra.DEC@decwrl.dec.com> Subject: RE: DES checksum signatures >It is true that simple checksums are easy to defeat. I suggest considering >using the DES algorithm in the following manner. First, consider the file as a >sequence of 8 byte blocks (64 bits). Encrypt each block using a public and >known password, and add the result to a running total, 64 bits wide. At the >end, you have a 64 bit checksum. I doubt anyone reading this is cabable >of modifying the original file so as to calculate this checksum. Cryptography (and especially cryptographic checksums) is a complicated field, and is it difficult for a novice to determine how difficult a scheme is to defeat. The checksum you mentioned is trivial to defeat. Here is the method to defeat that checksum: Since the key is known, the intruder trying to modify the file can calculate the original checksum. The intruder modifies the file, but saves one 8-byte block that is never referenced and can have an arbitrary value. The checksum for the modified file is calculated (ignoring the spare block), and the difference between the original checksum and the new checksum is determined by subtraction. This difference is decrypted with the known key and placed in the spare 8-byte block in the file. This modified file now has the same checksum as the original file. Even if the key is not known, there is an additional attack against this checksum: individual 8-byte blocks of the file can be transposed and the checksum remains the same. This is not likely to be useful to someone who wants to create a virus, but is a concern if general file integrity is important. DES has a defined chaining mode (CBC--Cipher block chaining) where a series of blocks is encrypted with the result from each encryption step feeding into the next step. CBC mode has nice properties for encryption, but, again, an integrity check using CBC mode with a known key can easily be circumvented. [However, changing the order of blocks can be detected if the key is not publicly known.] A simple way to use DES and a known key to build a good (cryptographically secure) checksum scheme would be very useful, but I don't know of any that have been demonstrated to be secure. [One step further: It would be nice if the developer of the software could generate the cryptographic checksum and distribute it with the software. This results in another problem to solve: How the correct checksum can be securely distributed.] B.J. ========================================================================= Date: Fri, 13 May 88 12:50:00 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Dr. Woody" <WWEAVER@DREW> Subject: verification of authorship of computer programs One problem we have been dealing with is verification of authorship of computer works, whether executables or source code. (People feel better if they have the source - but I don't know about you guys, but if I'm presented with a 100K source file, I might not be able to detect a trojan...) This is a standard problem in cryptography. Probably the simplest solution applicable to the BBS system is to do the following: the author should choose his favorite two very very large primes, and publish and use their product in all his works. He can then encrypt his executable (or source code) so that a public key system can decrypt it. The author should, of course, put the public key with the cleartext documentation. The advantage is simply that a responsible BBS owner need only verify the existence of the author once, and can do it in a relatively compact fashion: he doesn't have to do a diff on files recieved, but only on the key. Moreover, the trojans we see today are typically revisions of already existing files (like the archive 1A => archive 1B) and so the BBS owner would know if a malicious user contaminated the file and resubmitted it: the key would change from the original author to one devised by the malicious user. One disadvantage of course is that decoding the file is made more computer resource intensive. What price security? I would not mind running an extra layer to verify that the author is who he says it is. A submission of a program not by the author would decrypt to gibberish. (With some authors, even the real program decrypts to gibberish... ;-) ) Of course, what will probably happen is that unsophisticated users will distribute already decrypted images. However, at least the BBS owners have the ability to store only author-encrypted files and preserve the BBS's integrity for trojan-free files. woody weaver wweaver@drew ========================================================================= Date: Fri, 13 May 88 12:49:00 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Dr. Woody" <WWEAVER@DREW> Subject: detecting data alterations via CRC One of the thoughts for detecting differences in files has been to write down a checksum signature with the file. The problem, of course, is that if the virus author realizes that his creation is subject to, say, CRC detection, then he will have the virus upon infection compute the CRC of the file, and then alter sufficient bytes to preserve the CRC. It has been pointed out that typical programs are measured in the kilo- byte, while signatures are measured in bytes; since the map is from a larger set to a smaller set, the map can not be 1-1. One solution to this was, as someone observed, is that there is more than one cyclic polynomial that can be used: after all, fields have lots of primitive elements. If the CRC polynomial can be chosen from one of m (where m is in the thousands), and there is only a probability of 1 in 2^n of the virus accidentally preserving the CRC checksum then the probability of correctly preserving all of the CRC polynomials is 1 in 2^mn. Of course, that means that the checking program would have to compute all m CRC polynomials. More likely, the program would sample 2 or 3 CRC values; most people can live with a likelyhood of 1 in 2^3n of the virus accidentally preserving the checksum. One problem is that the virus need not accidentally preserve checksums. The virus could concievably satisfy *ALL* of the CRC polynomials, provided it knew how large the signature n was. (This assumes that the input set is larger than 2^mn.) The chief advantage is that in order to be able to have self replicating code with an infection scheme this complex, the virus would have to be large and the infection process would be slow, consuming a (hopefully) visible fraction of computing resources. Fat and slow viruses can be detected, and after detection hopefully cured. An alternative, for the people who are especially concerned about security and are willing to devote a larger fraction of their resources can use a CRC scheme with site dependent signature size. In this fashion, the virus can not know in advance the detection scheme the site will use, and so the infection passing the signature-preservation test will be back to random, and a probability most people can live with. woody weaver wweaver@drew ========================================================================= Date: Fri, 13 May 88 08:28:10 CDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Craig Pepmiller <CCCRAIG@UMCVMB> Subject: Signature lengths It is not strictly true that a signature must be as large as the file checked to avoid many-to-one mapping. An easy way to prove this is data compression. It is easy to construct a file that uniquely identifies a larger file if the source has repeating patterns or other features that are compressible. Another thought for budding compu-epidemiologists; There is a set of unique machine instructions that a virus must use to work. If you compress all the bytes that are not part of that set then you can have a signature that is much much smaller than the original and still identify the vital parts of the file. This would not work on programs that are meant to unpack and execute other files (ie BASICA) or where a change in an argument can bring in unchecked code. Maybe you would have to check disks in their entirety. Any comments? What set of instructions would need to be part of the set? Should this be a thesis project for somebody (maybe me)? Think about it, Craig Pepmiller Comp. Prog./Anal. II University of MO-Columbia Bitnet: CCCRAIG@UMCVMB ========================================================================= Date: Fri, 13 May 88 13:59:24 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1> Subject: Checkup I just downloaded Checkup 1.4 from the author's own bbs (215-969-8379). Rich Levin, the author, tells me that version 1.5 should be out within a week or so. I'll post it as soon as it's available. I was unable to find any differences between the file that I downloaded and the one which I had previously posted. I think that Flu_Shot+ was displaying incorrect error messages - but I could be wrong... I did have some other problems with Flu_Shot+ interfering with a couple other programs, for what that's worth. Anyway, you can all rest assured that the Checkup file on VIRUS-L is as the author intended for it to be. The filename is still CHKUP14 UUE on this LISTSERV. Ken ------------------------------------------------------------------------ = Kenneth R. van Wyk = = = User Services Senior Consultant = Badgers! We don't need = = Lehigh University Computing Center = no stinkin badgers! = = Internet: <LUKEN@VAX1.CC.LEHIGH.EDU> = = = BITNET: <LUKEN@LEHIIBM1> = = ------------------------------------------------------------------------ ========================================================================= Date: Fri, 13 May 88 14:45:08 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "David M. Chess" <CHESS@YKTVMV> Subject: Signature lengths > From: Craig Pepmiller <CCCRAIG@UMCVMB> > It is not strictly true that a signature must be as large as the file checked > to avoid many-to-one mapping. An easy way to prove this is data compression. That's a point; the true statement is more like that the signature of a *random* file must be, on average, as large as the file to be checked (if you run a data-compression program on a file of truly random bits, the file usually gets larger...). If I had any faith in my understanding of the concept of information, I'd say that a one-to-one mapping is only possible if the elements of both sets contain the same amount of information... > Another thought for budding compu-epidemiologists; There is a set of unique > machine instructions that a virus must use to work. Could you elaborate on that? The instructions that a virus needs to work are generally the same instructions that any other program needs to do anything else (adds, moves, operating-system calls). You could probably identify a set of bytes and say "any virus must contain at least one of these", but it's not clear to me how that would aid in compression and signature-making. Sounds interesting, though; could you give more details? (Unless you think I'm the only one who doesn't understand, in which case write me a note and scold me!) DC ========================================================================= Date: Fri, 13 May 88 20:35:22 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> Comments: In-Reply-To: 13 May 88 08:28:10 CDT from Craig Pepmiller From: Otto Stolz +49 7531 88 2645 <RZOTTO@DKNKURZ1> Subject: Signature lengths > There is a set of unique machine instructions that a virus must use to > work. True. > If you compress all the bytes that are not part of that set then you > can ... still identify the vital parts of the file. False!! Using specific instructions doesn't imply having these very instructions in the executable program file. The virus could well compose those vital (and revealing) instructions on the fly from totally unsuspicious material. E.g. it could subtract some register's contents from itself to fabricate zero, increment and shift it several times to produce an arbitrary OP-code, store it to memory and eventually jump to this very memory location. Hence, all OP-codes belong somehow to the vital set. Think about it. Best regards Otto ========================================================================= Date: Fri, 13 May 88 12:26:00 EST Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: GILL@QUCDNAST Subject: More FLUSHOT+ bugs Now that someone mentioned it, I had the CMOS problem as well, but on an IBM-PC clone (no XT or AT!) - my machine is a Zenith 151. From the FLUSHOT+ documentation, I didn't even realize that my CMOS could even be changed - it implies this is a purely AT possibility. Arnold Gill Queen's University at Kingston gill @ qucdnast.bitnet ========================================================================= Date: Fri, 13 May 88 17:01:23 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Russell Nelson <nelson@clutx.clarkson.edu> Subject: All Things Considered There will be a report on the Israel University virus tonight on NPR. Catch it on your local public radio station. This report might be repeated on next morning's Morning Edition. -russ ========================================================================= Date: Fri, 13 May 88 12:20:00 EST Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: GILL@QUCDNAST Subject: Question about CRC protection As I understand CRCs, the CRC is a particular polynomial function of the bytes within a file. If that is the case, would it not be possible to devise two (or three) orthonormal CRC polynomials, such that any illegal change in the programs constant would necessitate a change in one or more of the CRCs? A virus could make one of the CRCs come out all right, but several orthonormal ones? If such an idea is possible, then virus protection becomes simply a matter of saving and safely protecting ones CRC list. Of course, I may be wrong. Being in physics means I'm not overly concerned with uniqueness proofs. :-) Arnold Gill Queen's University at Kingston gill @ qucdnast.bitnet ========================================================================= Date: Fri, 13 May 88 12:33:29 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Neil Duffee <NJD2F@UOTTAWA> Subject: XMAS EXEC add'l comments some additional comments on the CHRISTMA EXEC: The above virus (which arrived here with the name XMAS EXEC) more likely relied on our trust because it was, after all, sent to us from a friend at another node, was it not? Since we trust our friends, why not just run it? (besides, at that time, virii were limited to micros and not mainframes) Locally, the operators (and prob. the system manager) did a periodic check of the spool files and purged about 200+ files manually. (we are a rather peripheral node) Neil Duffee Computer Operator University of Ottawa Ottawa, Ontario, Canada NJD2F@UOTTAWA.BITNET (soon to become NJD2D@UOTTAWA.BITNET) ========================================================================= Date: Sun, 15 May 88 19:11:29 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Jim Frost <madd@bu-it.BU.EDU> Subject: Re: software self-checks |> |however, such checks would be very useful in slowing the spread of a virus. |> |> A couple of comments to this. Yes, it'd slow the spread of |> viruses, but it would also make you less paranoid about them (and |> thus less likely to catch them), | ---- | I assume this should have been MORE likely to catch them? No, I meant less. If a virus was built that circumvented the checks, you'd probably never find it because you're not looking for it under the assumption that if it were there, you'd be told. jim frost madd@bu-it.bu.edu ========================================================================= Date: Mon, 16 May 88 04:42:20 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Amanda B Rosen <abr1@cunixc.columbia.edu> Subject: Various protection schemes against executable-infecting viruses Hi... first posting for me... About the one-to-one mapping, I believe that it has already been mentioned that data compressors generate unique "signatures". In fact, for any desired amount of certainty, there will be a spectrum of algorithms you can use, ranging from storage-intensive, computationally undemanding ones to ones which make great demands on the CPU but generate much smaller signatures. For example, given a desire for 100% certainty, you could copy the file (for a disk-intensive scheme) or Huffman-encode it (CPU-bound). Likewise, for less certainty you could keep a large checksum or a small CRC. Without giving the matter much thought (yet), I wonder if Huffman encoding might not be a useful tool in the Virus wars. Of course, it makes large demands on the processor, but you don't need to huf the whole file. I am guessing now, but I bet that a 'database' type analysis which huf'ed a file and kept just the table could defeat every file-modifying virus out there today. Unfortunately this takes a lot of time. The $64K question is, are there any Huffman-type schemes which take less time, but have the same basic character? The reason I am intruiged by Huffman is that it analyzes the character of the data in the file. An example of another, very simple analysis scheme is one that counts the number of occurences of each byte value in the file. This would be difficult to defeat, because the virus would probably have to alter such a large part of the infected program to conform to the validation check that the program wouldn't be able to execute at all. Why does everyone assume that a 'database' validation scheme must use only one type of check? Having a variety of simple checks available and randomly choosing two for each file to be validated (you store the types of the checks along with their results) should be enough to stop any virus. So... am I missing something? /a ========================================================================= Date: Mon, 16 May 88 14:03:00 LCL Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Michael Wagner new! +49 228 8199645 <WAGNER@DBNGMD21> Subject: Re: software self-checks > From jim frost <madd@bu-it.bu.edu> > |> A couple of comments to this. Yes, it'd slow the spread of > |> viruses, but it would also make you less paranoid about them (and > |> thus less likely to catch them), > | ---- > | I assume this should have been MORE likely to catch them? > > No, I meant less. If a virus was built that circumvented the checks, > you'd probably never find it because you're not looking for it under > the assumption that if it were there, you'd be told. When I catch a virus, that is to me like catching a cold, i.e. contracting, getting sick, etc. That is how I read your comment. I think you meant catching as in detecting, trapping, immobilizing, etc. It seems I understood the opposite meaning from what you intended. Ah, the dangers of mixing vocabularies willy nilly from different fields. Michael ========================================================================= Date: Mon, 16 May 88 12:18:00 PDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: WETTERN@OREGON Subject: RE: XMAS EXEC add'l comments I just wanted to let you know that there are at least two legitimate programs called XMAS EXEC out there. One of them, for example, is a cute little animated thing coming from Japan. So, when next xmas comes around and somebody sends you a XMAS EXEC, check it out before you run or discard it. It might be a virus or something legitimate. ========================================================================= Date: Mon, 16 May 88 14:07:00 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Woody <WWEAVER@DREW> Subject: detecting damaged data I think we've become a bit distracted on the problem of virus detection. There seem to be two essential problems: first, making sure that the program you recieve is free of viruses (and destructive code -- i.e. the authorship problem) and ensuring that your data does not become contaminated over time. The current discussion seems to be revolving about the latter half of the problem: we would like to ensure that the executable image we are about to launch (or data base we are about to access) has not been altered by a malefic agent. Someone (sorry, threw away that message) proposed storing a CRC signature for each file. Jerry Leichter (LEICHTER@YALEVMS) responded >Unfortunately, it is very easy to modify a file so that any given CRC remains >unaltered. The protection you get by using a CRC is thus quite limited - it >stops those virus-writers who aren't clever enough to work around it. This is an inherent problem: if we use a simple protection scheme, then the virus can include code to defeat it. Varying what is meant as "simple", while looking at the code to CHECKUP, Kenneth R. van Wyk (LUKEN@LEHIIBM1) remarked >This raises an interesting question - is it truly possible to write >a checksum/crc/whatever algorithm that will be able to figure out >whether or not a file has been changed 100% of the time? Let's assume >that the signature data has *not* been tampered with in any way. It >is no secret that both checksums and crcs can be circumvented rather >easily. But, an algorithm which could validate a file with 100% >effectiveness could be very worthwhile looking into. Once again, the >validity of the signature data itself would have to be insured via >encryption and/or read-only isolation. David M. Chess (CHESS@YKTVMV) gave an argument to answer van Wyk's question in the negative: essentially, it is that the number of possible messages is larger than the number of possible (small) signatures. No one - to - one function maps a larger set into a smaller set. However, Leichter's original post goes on to point out the following: >I would suggest a compromise: A mechanism that, while not completely secure, >makes things very hard on a virus-maker while not requiring huge amounts of >computation. When a program is published, a large number of random polynomials >(say, 100 or 1000) are chosen, using the techniques of Rabin's paper. The CRC >of the program with ALL the polynomials is published. To check a program, you >chose any two of the polynomials - also published - compute the CRC's, and >compare. (You must, of course, chose those two at random.) The virus maker >must make his program have the same CRC with respect to ALL the 100 or 1000 >polynomials - which is possible, but requires (I believe, this would need to be >studied) a LOT of computation. (The length should probably be checked - it's >going to be a lot easier on the virus maker if he can add extra stuff to the >end of the program to make the CRC's come out right.) Professor Leichter is trying to simultaneously solve the authorship problem and the preservation of data problem by publishing this list with the program. One of the problems with this is that we still have to find some way to publicly distribute this list, and then have to store this list (no small overhead!). However, if we just consider trying to stabilize the data, this is quite a useful system. When the file is recieved (or legally modified) a collection of 100 or 1000 (or 10, site dependent CRC polynomial signatures) are chosen and stored separate from the file. Now, at appropriate intervals, one or two of the CRC polynomials from the stored list are selected, are computed for the file, and compared against the stored signatures. If a difference is detected, we know the file is contaminated and appropriate measures can be taken. In some sense, this is appealing to Arnold Gill's intuitive feel for the effect of CRC error detection: > As I understand CRCs, the CRC is a particular polynomial function >of the bytes within a file. If that is the case, would it not be >possible to devise two (or three) orthonormal CRC polynomials, such that >any illegal change in the programs constant would necessitate a change >in one or more of the CRCs? A virus could make one of the CRCs come >out all right, but several orthonormal ones? If the virus knows which (small number of) CRC's are going to be checked, it (theoretically) can alter the data to preserve all signatures. If it doesn't know which CRC's are going to be checked, it can only preserve them randomly. If we can treat the virus as a random rather than intelligent agent, then we achieve detection approaching that of noisy telephone lines, for which CRC's are excellent. The chief advantage of this scheme is that we are drawing upon the essence of zero knowledge proof to verify the identity of the data. While a virus could contaminate a specific site (because for a specific site the inquiry is predetermined: the virus need only defeat a small number of detection functions) general transmission of the virus is not possible; once such a virus is detected at one site, avenues of communication (such as this list) will alert other sites where it may have escaped detection and it can be killed net-wide. An important feature of this scheme is that it requires a small amount of overhead (only a few signatures stored at any one site, instead of all of the signatures stored at every site) and can be done quickly (little more than reading the entire file). It seems clear to me at least that detection schemes that require extensive storage or processing will not be enacted -- I mean, given sufficient storage, one would simply keep a spare copy of the data on a WORM -- so this at least has a possibility of being followed in the interests of good computer hygiene. ========================================================================= Date: Mon, 16 May 88 14:37:41 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: riacs!ames!hc!csed-1!csed-47!roskos@rutgers.edu Subject: Re: Signature lengths >> It is not strictly true that a signature must be as large as the file checked >> to avoid many-to-one mapping. An easy way to prove this is data compression. > >That's a point; the true statement is more like that the signature of >a *random* file must be, on average, as large as the file to be checked ... No, that's not quite right. All the "counterexample" shows is that there may be a bijective mapping from the set of all signatures of n bits to some *subset* (of size 2^n) of the set of all files of m bits, m > n. As I mentioned in my previous message to VIRUS-L(1), it is the *number of distinct values the program file can take on* that determines the size of the signature required, not the number of bits in the program file per se. If you allow the n-bit signature to include a program with more than n bits, there will be a program of less than or equal to n bits for which there is no n-bit signature. A compression algorithm just tries to take the most "frequently occurring" values of an m-bit file and give them representations in n bits. Consider that it is not possible to compress all files, as Mr. Chess points out; that is because in n bits you can't represent all m bit files, just as you can't represent all m bit files in an n-bit signature. In other words, compression would be analogous to finding a function that assigns a unique n-bit number to each *existing* program you have (where there are less than 2^n programs in existence). This may well be possible (although in the worst case the function might have to have a copy of each program to compare with the one being tested). Really, though, the function would have to do slightly more than that; it would also have to return some special value for all programs that didn't match, so you can tell when you have a modified one. >> Another thought for budding compu-epidemiologists; There is a set of unique >> machine instructions that a virus must use to work. > >Could you elaborate on that? The instructions that a virus needs to work >are generally the same instructions that any other program needs to do >anything else (adds, moves, operating-system calls). That's true. It's not really the set of unique machine instructions, but rather the instruction *sequences*. Correctly-working programs use these same instructions (maybe through a mediator, the operating system), they just don't use them to infect other programs. However, machines that provide "hardware protection" features do use exactly the principle stated in the part with the ">>" above; these are the "privileged instructions" (which may take the form of privileged system calls). If you restrict this set of instructions to be used only by code which is proven to protect against virus-operation (this includes protecting the protection code itself, and other things generally associated with a secure system), then you have a system which is "secure," which is the source of much work these days. But, notice that it gets increasingly hard to fully protect a system in this way; for example, you would have to have the restriction that only compilers can modify object files, for instance; i.e., the system would have to distinguish writes to a user's file that result from the user recompiling the program, from writes to the same file that occur due to some other program trying to modify it to insert a virus. Now that I think about it, that is not as hard as it first seems, it's just not something that is usually provided nowadays. It would require one to be very rigorous in the design, but it does seem as though it could be done... ------ (1) I haven't seen my previous message appear on the list, though, so it may have been lost on the way to LEHIIBM1. Eric Roskos, IDA (csed-1!roskos@DAITC.ARPA or Roskos@DOCKMASTER.ARPA) ========================================================================= Date: Mon, 16 May 88 15:01:23 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: riacs!ames!hc!csed-1!csed-47!roskos@rutgers.edu Subject: need RISKS LOG Is there anyone out there who would be willing to send me the RISKS LOG on a floppy disk? I will send you the postage required. I am preparing a report on viruses and need the log fairly soon (at least by the first of next week). I have been trying for several weeks to get a copy via GET RISKS LOG but, although I get the report back from the list server saying the job has run, the log never arrives. Apparently someone's mailer is discarding it along the way. If you are willing to do this, email me about it so we can work out how to send it. Thanks... -- Eric Roskos ========================================================================= Date: Mon, 16 May 88 14:47:08 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: riacs!ames!hc!csed-1!csed-47!roskos@rutgers.edu Subject: Re: The neverending chain.... In the future, "hardware" protection is probably going to be a neccessity. Hopefully, it won't inhibit system "friendliness" and utility too much. (Remember, the most secure and protected system to date is one which is totally isolated and restricted...and who wants one of those? Yeeek) Actually, the goal of a secure system should be to prevent "illegal" accesses while providing a minimum of interference to "legal" accesses. This is what makes it more challenging. Note, though, that *some* overhead is necessary, simply because it requires more work to check that an access is "legal" than just to allow all accesses. But it doesn't follow that the overhead has to be intolerably high... ========================================================================= Date: Tue, 17 May 88 04:19:54 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Amanda B Rosen <abr1@cunixc.columbia.edu> Subject: Detecting damaged data Shortly after I posted some thoughts concerning the usefulness of keeping several (random) signatures for every file, Woody(WWEAVER%DREW.BITNET) posted a long, well-written article declaring that this is exactly the right thing to do. He still mentions only CRC's, though. Why are they considered the best signatures? Is there a particularly easy way to defeat byte-counters (or nibble counters, if you can't store a 256 word signature)? It seems to me that in order to check files sufficiently often, the CPU overhead must be *very* light. Disk storage, however, is at much less of a premium. Even a 256 word signature would be a tiny percent of the actual file's size, and the byte-counting algorithm is very cheap. /a ========================================================================= Date: Tue, 17 May 88 12:52:00 CET Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Karl-L. Noell" <NOELL@DWIFH1> Subject: CRC Signatures not reliable at all ? Several discussion remarks have objected, that CRC signatures wouldn't be able to protect against intentional file tamperings. This holds true only under the following assumptions: 1. A CRC based protection scheme is utilized. 2. The certain G(x)=... is the current (and public known) denominator polynomial to calculate the signature, and 3. the original (untampered) file yields to the very remainder R(x)=... considered as the signature of the clean file. To succeed in his impious attempts, an evil-doer must exactly know really *everything* stated above (1.,2.,3.). Then it's indeed possible to 'adjust' the CRC signature to get the expected value even after files have been altered. For this reason, CRC signatures can't provide sufficient security if one intends to protect the public *distribution* of files showing, that they are coming from trustworthy sources. Nevertheless CRC signatures can be fairly reliable to protect files from getting tampered *subsequently* during running for applications. If you chose an arbitrary G(x) and *not* the polynomials standardized by CCITT, and if you alter *your* G(x) from time to time, how should another person be able to know about this scheme ? Keeping and com- paring weekly logs reporting file sizes, time date stamps *and* CRCs (computed with home made and sometimes changed polynomials) will give a fair chance to detect suspicious events. I believe such imperfect methode is still better than taking no care at all whilst waiting for the 'great and entirely secure' solution. Karl Noell ========================================================================= Date: Tue, 17 May 88 07:22:00 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Woody <WWEAVER@DREW> Subject: re: Detecting damaged data Amanda B Rosen <abr1@cunixc.columbia.edu> asks >Why are they [CRC checks] considered the best >signatures? Is there a particularly easy way to defeat byte-counters (or >nibble counters, if you can't store a 256 word signature)? Actually, I don't think there is a "best" scheme. To defeat a particular CRC check, you have to make sure that your virus maps the binary polynomial of the corrupted file (mod the CRC polynomial) to the binary polynomial representing the true file (mod the CRC polynomial). To defeat a byte counter, you have to make sure the corrupted file has the same bytes as the true file (though presumably in a new order). The thing is, though, if you devote that 256 word signature to a CRC check, we have 2^256*(wordsize) different possible states that can arise as residues. Moreover, there are good mathematical reasons to believe that these different states occur with equal frequency. If you devote that 256 word signature to a byte counter then not all 2^256*(wordsize) bit patterns arise: moreover, I would suspect that the counts for most executable files have about the same percentages of each operation. The lack of randomness makes the test less effective. However, most people want to check the size of the file as part of the corruption check -- the idea of a byte counter is simply a generalizaton of that examination. She continues >It seems to me that in order to check files sufficiently often, the CPU >overhead must be *very* light. Disk storage, however, is at much less of a >premium. Even a 256 word signature would be a tiny percent of the actual >file's size, and the byte-counting algorithm is very cheap. Absolutely. If we want to add this check to a segment loader as part of the operating system, it needs be fast indeed. As I recall, the CRC check is done by fairly simple shifting and mod 2 addition: in both the byte counting algorithm and the CRC check algorithm, the actual check is a small fraction of the time required to retrieve the file from storage. Is a CRC check before launch being done anywhere? Even a simple parity check (i.e. CRC with polynomial x + 1)? Why not? ========================================================================= Date: Tue, 17 May 88 08:37:26 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Otto Stolz +49 7531 88 2645 <RZOTTO@DKNKURZ1> Subject: Special Warning on 3 infected MacIntosh programs Hello, A couple of minutes ago, I run into a letter dated 21th March 1988, that was circulated by a Software Distributing House in southern Germany to their customers. I will not post their name or address to this list; if somebody really needs it, please drop my a note, privately. As I don't have access to a MacIntosh, I can't assess the importance the message might bear to MacIntosh users; so I deemed it best posting it in this list for anybody who might be concerned. As none of the programs below is mentioned in the DIRTY DOZEN, somebody (Ken Van Wyk?) should forward this note to Eric Newhouse whose BITNET address is unknown to me. Following is the main part of this letter (translated into English): > Subject: MacIntosh Virus!!! > > Regrettably, also MacIntosh has been befallen by some virus, meanwhile. > Please do *not* use any of the following programs: > Pre-Release PageMaker 3.0 > Pre-Release HyperCard German > Pre-Release Multifinder German > > *Beware:* Virus spreads through networks (e.g. AppleTalk)!!! > > Symptoms: Difficulties when using the Hard Disk, even to the amount > of completely loosing the Hard Disk. Best regards Otto Stolz ========================================================================= Date: Tue, 17 May 88 10:08:20 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> Comments: Resent-Date: 17 May 1988, 15:49:32 +0200 (MESZ) Comments: Resent-From: Otto Stolz +49 7531 88 2645 RZOTTO at DKNKURZ1 From: Otto Stolz +49 7531 88 2645 <RZOTTO@DKNKURZ1> Subject: Special Warning on 3 infected MacIntosh programs The following contribution came back to me from somewhere down the line for a reason I couldn't figure out from the accompanying message. As I'm not sure wether it has already reached the relvant LISTSERV, I'm going to post it again. Hello, A couple of minutes ago, I run into a letter dated 21th March 1988, that was circulated by a Software Distributing House in southern Germany to their customers. I will not post their name or address to this list; if somebody really needs it, please drop my a note, privately. As I don't have access to a MacIntosh, I can't assess the importance the message might bear to MacIntosh users; so I deemed it best posting it in this list for anybody who might be concerned. As none of the programs below is mentioned in the DIRTY DOZEN, somebody (Ken Van Wyk?) should forward this note to Eric Newhouse whose BITNET address is unknown to me. Following is the main part of this letter (translated into English): > Subject: MacIntosh Virus!!! > > Regrettably, also MacIntosh has been befallen by some virus, meanwhile. > Please do *not* use any of the following programs: > Pre-Release PageMaker 3.0 > Pre-Release HyperCard German > Pre-Release Multifinder German > > *Beware:* Virus spreads through networks (e.g. AppleTalk)!!! > > Symptoms: Difficulties when using the Hard Disk, even to the amount > of completely loosing the Hard Disk. Best regards Otto Stolz ========================================================================= Date: Tue, 17 May 88 08:40:00 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Joseph M. Beckman" <Beckman@DOCKMASTER.ARPA> Subject: Re: checksum signatures In-Reply-To: Message of 12 May 88 09:15 EDT from "Kenneth R. van Wyk" 1. It is patently false that a checksum algorithm can (with an accuracy of 100%) detect changes to a file. I am assuming that "checksum" here means some "encoding" of the file that *is less lengthy* of the file itself. Consider this: let's let xx represent files, y represent the checksum. If we only use digits for this example, there are 100 different files that can exist, 10 different checksums. Clearly, one checksum "covers" 10 files. Although you can do certain other things (in addition to "pure" checksums), you would (?) have to *be able to recreate the original file* from the "checksum" (and whatever else you looked at) in order to claim 100% detection. Anything less says that there is a possibility of "collision." If you make a backup of a file & then do a compare, that would give you 100% (with certain assumptions); or even if you could compress the file & back that up. It may be that you can achieve 100% detection with less if you make certain assumptions about what the file will or will not contain; but if you are talking about arbitrary strings, such an assumption is not valid. Joseph ========================================================================= Date: Tue, 17 May 88 17:18:00 LCL Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Michael Wagner new! +49 228 8199645 <WAGNER@DBNGMD21> Subject: Re: Detecting damaged data > From: Woody <WWEAVER@DREW> > > Is a CRC check before launch being done anywhere? Even a simple > parity check (i.e. CRC with polynomial x + 1)? Why not? I believe OS-9 has always done this. Even on slow 1MHz 6809s, the delay was never objectionable. The point was not to detect viruses, but rather to provide some minimal protection against calling programs that had suffered damage on disk and had passed the rather simplistic old disk data validation checks. This was especially important on a cpu that had no memory protect and no supervisory/user mode capabilities. I don't recall the details of the algorithm any more, but I can find out if anyone is interested (private mail, please - don't tell the whole list). It was so simple at thing to do, and offered considerable protection. I never understood why no other micro-os manufacturer did it. Michael ========================================================================= Date: Tue, 17 May 88 12:59:00 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Woody <WWEAVER@DREW> Subject: re: CRC signatures not reliable at all ? Karl Noell <NOELL@DWIFH1> (Germany! Isn't BITNET a great communication network?) writes >Several discussion remarks have objected, that CRC signatures wouldn't >be able to protect against intentional file tamperings. >This holds true only under the following assumptions: > 1. A CRC based protection scheme is utilized. > 2. The certain G(x)=... is the current (and public known) > denominator polynomial to calculate the signature, and > 3. the original (untampered) file yields to the very remainder > R(x)=... considered as the signature of the clean file. >To succeed in his impious attempts, an evil-doer must exactly know >really *everything* stated above (1.,2.,3.). Then it's indeed possible >to 'adjust' the CRC signature to get the expected value even after >files have been altered. [...] I'd like to point out he needn't really *know* all that. Let us suppose that the virus writer knows that 1 is true. Also, suppose that the virus writer does not *know* the G(x) of 2, but suspects it is one of g1(x), g2(x), ... gk(x). Write G(x) = g1(x) * g2(x) * ... * gk(x), and set ti(x) = G(x) / gi(x) (for i = 1 .. k ). For a fixed remainder gi(x) he precomputes mi(x) so that mi(x) * ti(x) = 1 mod gi(x). (Such exist from the chinese remainder theorem, because the CRC polynomials are relatively prime.) Set p(x) to be the clean file, interpreted as a binary polynomial. Compute r1(x), r2(x), ... , rk(x) the remainders mod g1(x), g2(x), ... , gk(x) respectively. Form r(x) = sum { ri(x) * mi(x) * ti(x) } mod G(x). The virus need only do the following: (1) analyze the executable image, and find a routine that is rarely executed. Carefully jump around that routine, and use the space for his viral code. Alter p to form an infected, virally communicating file p'(x). Save a bit more space that we will use as free variables. (2) Alter p'(x) to p*(x) by manipulating that free space so that p*(x) = r(x) mod G(x). Now, no matter which CRC check g1(x) to gk(x) is run, p*(x) has the same residue as the 'clean' file p(x). There is no way to defend against that, provided the invading virus does know that you are using a CRC check and has a (short) list of CRC polynomials to protect itself against. There is considerable hope, however. The computation involved in obtaining r(x) is nontrivial. Moreover, the 'save a bit more space' may also be nontrivial: to match the residue mod G(x) it could be necessary to use up to degree(G(x)) bits and this is the degree of the CRC check times the number of potential checking polynomials: with a sufficiently large CRC check signature and sufficiently many candidates for check polynomials, our virus writer can't write an undetectible virus. Anyway, Karl Noell goes on to observe >If you chose an arbitrary G(x) and *not* the polynomials standardized >by CCITT, and if you alter *your* G(x) from time to time, how should >another person be able to know about this scheme ? Keeping and com- >paring weekly logs reporting file sizes, time date stamps *and* CRCs >(computed with home made and sometimes changed polynomials) will give >a fair chance to detect suspicious events. I believe such imperfect >methode is still better than taking no care at all whilst waiting >for the 'great and entirely secure' solution. A person could know your CRC check polynomial because you aren't clever enough in concealing it. Suppose you have a file called MY_CRC_CHECK_POLYNOMIAL.DAT... I could have my virus look for such a file and use it. But seriously, this is the whole point. If we are able to assume that the virus does not know which of the CRC polynomials you are using (nor its size) then he can not protect completely against it. As long as we are dilligent and random, this is not an "imperfect methode" but safe protection against a random virus. A more serious problem however would be a program designed to specifically live inside a specific site or system. For a specific site, the randomness of the CRC is no protection. But then, this is virus-L, not ICE-L... woody ========================================================================= Date: Tue, 17 May 88 08:42:00 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> Comments: Resent-From: "Joseph M. Beckman" <Beckman@DOCKMASTER.ARPA> Comments: Originally-From: "Joseph M. Beckman" <Beckman@DOCKMASTER.ARPA> From: "Joseph M. Beckman" <Beckman@DOCKMASTER.ARPA> Subject: Re: hunting up infected files In-Reply-To: Message of 9 May 1988 11:05 edt from Karl-L. Noell As an employee of the National Computer Security Center, I must point out that we do *NOT* attempt to track perpetrators for prosecution or for *ANY* other reason! We are not a law enforcement Agency, and are prohibited by law to take any such action. We are interested in tracking the viruses (or ordinary Trojan Horses) as they infect different sites. As a matter of professional interest, I would be curious as to the motivations of perpetrators of malicious code, or whether they are members of "Hacker Clubs;" but that is information that may be conveyed without identifying the people/organizations involved. Joseph ========================================================================= Date: Wed, 18 May 88 08:35:47 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1> Subject: Beware the turkey! :-) Here's a forwarded message that I got. The program described here looks almost like a new CHRISTMA EXEC - if anyone has any more information on this, please send it to the list. To: ICS@ruby-falls.ICS.UCI.EDU Subject: Warning! Date: Thu, 12 May 88 13:07:21 -0700 From: Tim Morgan <morgan@ruby-falls.ICS.UCI.EDU> Everyone should be aware of the program described in the following message. We don't want to have to restore any files for anyone... Date: Tue, 10 May 88 12:48:16 PDT From: Doug Fouts <fouts%krypton@hub.ucsb.edu> To: jwills@venera.isi.edu Subject: EMAIL WARNING I have just been informed by a friend of mine here at U.C.S.B. that there is a program being passed around via ARPAnet (and also some other computer networks) that is called "turkey". The instructions that are sent with the program say that when compiled and run the program will draw a nice picture of a turkey. I have been informed that the program is a (not very funny) joke. It does not draw a turkey, but it does erase all of the unprotected files in your directory. You might want to pass this information along to people you know who use the network, as I am doing. Doug Fouts ------------------------------------------------------------------------ = Kenneth R. van Wyk = = = User Services Senior Consultant = Badgers! We don't need = = Lehigh University Computing Center = no stinkin badgers! = = Internet: <LUKEN@VAX1.CC.LEHIGH.EDU> = = = BITNET: <LUKEN@LEHIIBM1> = = ------------------------------------------------------------------------ ========================================================================= Date: Wed, 18 May 88 14:49:00 LCL Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Michael Wagner +49 228 8199645 <WAGNER@DBNGMD21> Subject: Re: CRC signatures not reliable at all ? > From: Woody <WWEAVER@DREW> > > There is considerable hope, however. The computation involved in > obtaining r(x) is nontrivial. ...with a sufficiently large CRC > check signature and sufficiently many candidates for check > polynomials, our virus writer can't write an undetectible virus. There is a very important point here, which I think needs to be stressed more than Woody is stressing it. A virus sophisticated enough to defeat the nontrivial schemes being proposed should be detectable either by the space it consumes or the time it takes up. This really the best we can hope for in these CRC schemes; to force such a virus into the domain of the visible. But we still have to have the tools to 'see' with. Therefore, computer users need to have precise tools to account for: 1. All consumed and free disk space 2. All consumed and free main storage in the running system 3. All consumed cpu time over some period of time. These tools are anyways useful to micro owners who want to better understand the workings of their micros, but they become absolutely necessary to manage the problems that occur when virii start sprouting up. If a certain, theoretically-unchanged operation starts taking significantly longer, it may have been subverted. To an extent, provision for these tools needs to be built in. For example, there should be no unaccounted-for storage on disk; the map should show it all, including boot blocks, fats, (skinnies,) whatever. Michael ========================================================================= Date: Wed, 18 May 88 08:56:04 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1> Subject: Re: CRC signatures not reliable at all ? In-Reply-To: Message of Wed, 18 May 88 14:49:00 LCL from <WAGNER@DBNGMD21> > This really the best we can hope for in these CRC schemes; to > force such a virus into the domain of the visible. > ... > If a certain, theoretically-unchanged operation > starts taking significantly longer, it may have been subverted. There certainly is a lot of truth in that; a virus that is sufficiently smart enough to get around the defense mechanisms proposed here would probably use enough CPU time such as to become noticable. Even the simple viruses seen so far can be noticed by someone who is truly used to the speed that his/her micro operates. However, you run into problems with this "method" of virus detection when (if?) you start to use multi-tasking operating systems like OS/2 and/or Un*x. Since several programs could be running at the same time in such a system, any one program could take a different amount of time to execute every time you run it. Ken P.S. I'm *not* trying to start a conversation on the merits of OS/2 vs. MS-DOS! Really, I'm not! ------------------------------------------------------------------------ = Kenneth R. van Wyk = = = User Services Senior Consultant = Badgers! We don't need = = Lehigh University Computing Center = no stinkin badgers! = = Internet: <LUKEN@VAX1.CC.LEHIGH.EDU> = = = BITNET: <LUKEN@LEHIIBM1> = = ------------------------------------------------------------------------ ========================================================================= Date: Wed, 18 May 88 15:52:00 LCL Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Michael Wagner new! +49 228 8199645 <WAGNER@DBNGMD21> Subject: Re: CRC signatures not reliable at all ? > Even the simple viruses seen so far can be noticed by someone who > is truly used to the speed that his/her micro operates. However, > you run into problems with this "method" of virus detection when > (if?) you start to use multi-tasking operating systems like OS/2 > and/or Un*x. Since several programs could be running at the same > time in such a system, any one program could take a different > amount of time to execute every time you run it. This was exactly my point (I guess I didn't express it very well). On simple systems, real time is (perhaps) an adequate measure. On multi-tasking machines (for me it's not when or if, it's how long ago. OS/9 and AmigaDOS were my last two micro operating systems; between them it's been five years since I used anything simpler), you MUST have ways to measure CPU consumed BY TASK/PROCESS. This implies that OS designers must build dispatchers that attribute all CPU consumption to the various consuming tasks. > Ken Michael ========================================================================= Date: Wed, 18 May 88 14:53:44 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1> Subject: forwarded submission Here's a forwarded message from J.D. Abolins: Re: Eric Rostov's request for copy of risks log on diskette... Eric or anyone else seeking for this and other files on diskette (5.25" >Diskette, msdos format), can snd me a stanped, self- addressed mailer to me at j. d. abolins 301 N. Harrison Street #197 princeton, NJ 08540usa (this is a mailing address only.) Daytime phone: (609) 292-7023 Besides the risks log, I have a number of other text files and articles concering the viruses. Photocopies of print articles can be made by arrangement. Re: the request to pass a message on virus-l to Eric Newhouse... I am going to send him a print copy of the message. Eric Newhouse, the developer of the dirty dozen listing, is not on bitnet. He is the sysop of the crest rbbs in california. the bbs number is (213) 471-2518. His mailing address is Eric Newhouse 1834 Old Orchard Road Los Angeles, CA 90049 usa Soon, I hope to send up the most recent version of the dirty dozen listing. j.d.abolins [Thanks for the generous offer J.D.!. -Ken] ------------------------------------------------------------------------ = Kenneth R. van Wyk = = = User Services Senior Consultant = Shocked! Shocked I am at = = Lehigh University Computing Center = this despicable act! = = Internet: <LUKEN@VAX1.CC.LEHIGH.EDU> = = = BITNET: <LUKEN@LEHIIBM1> = = ------------------------------------------------------------------------ ========================================================================= Date: Fri, 20 May 88 08:12:00 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Joseph M. Beckman" <Beckman@DOCKMASTER.ARPA> Subject: Re: Signature lengths In-Reply-To: Message of 16 May 88 14:37 EDT from "riacs!ames!hc!csed-1!csed-47!roskos%rutgers.edu at CUNYVM.CUNY.EDU" The capability to limit what programs can write to executables, etc., is a capability we are building into the LOCK (LOgical Coprocessing Kernel). This is done by assigning a "domain" to every subject (program) and a "type" to every "object" (file). There is an access matrix to determine which domains have (a particular) access to types. So if you have a type called "executable", only a subject in domain "trusted compiler" would have write access to it. This is a very powerful integrity tool, which will allow us to make some very strong assertions about how (if any) viruses could exist in such a "LOCKed" system. Joseph ========================================================================= Date: Fri, 20 May 88 08:46:35 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1> Subject: Re: Signature lengths In-Reply-To: Message of Fri, 20 May 88 08:12:00 EDT from <Beckman@DOCKMASTER.ARPA> >a capability we are building into the LOCK (LOgical Coprocessing >Kernel). Any chance of giving us VIRUS-L readers some more information on LOCK? I'm sure we'd all appreciate it. Ken ------------------------------------------------------------------------ = Kenneth R. van Wyk = = = User Services Senior Consultant = Shocked! Shocked I am at = = Lehigh University Computing Center = this despicable act! = = Internet: <LUKEN@VAX1.CC.LEHIGH.EDU> = = = BITNET: <LUKEN@LEHIIBM1> = = ------------------------------------------------------------------------ ========================================================================= Date: Fri, 20 May 88 09:07:02 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1> Subject: forwarded submission Here's a forwarded submission from J.D. Abolins: Ooops, my apologies. I had gotten the name wrong for the fellow who is looking for the copy of the RISKS LOG. I still don't have a copy of the original message from here at this site, but I think the name is more like Eric Roskos. But in any case, you know who you are and the offer for the doskette applies to anyone on the VIRUS-L list. (I prefer a stamped self-addressed disk mailer with a diskette or money to cover the disk and mailing.) Also I have sent up the DIRTY DOZEN listing, version 8 b. This came out in April 1988. J.D. Abolins ------------------------------------------------------------------------ = Kenneth R. van Wyk = = = User Services Senior Consultant = Shocked! Shocked I am at = = Lehigh University Computing Center = this despicable act! = = Internet: <LUKEN@VAX1.CC.LEHIGH.EDU> = = = BITNET: <LUKEN@LEHIIBM1> = = ------------------------------------------------------------------------ ========================================================================= Date: Sat, 21 May 88 23:21:00 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Joseph M. Beckman" <Beckman@DOCKMASTER.ARPA> Subject: Additional LOCK Info In-Reply-To: Message of 20 May 88 08:46 EDT from "Kenneth R. van Wyk" Re: LOCK One of the problems with building security into Operating Systems, has been the serial nature of a computer. When the user's program is operating, the security software is not. The user is then only constrained by what the TCB (trusted computing base) has done *before*. If there is a failure, and the user is jumped into mastermode, he can do whatever he wants. There is also an obvious performance penalty; the more security processing is necessary, the less time there is for user programs. LOCK is (essentially) adding a separate computer onto the computer to be secured (called the Host). This allows us to monitor without the performance penalty. It also allows us to keep the tcb code physically separate from user applications -- there is *no way* for the user to generate an address that reaches into the tcb code -- it is on a separate machine (albeit attached to the Host's bus). Most "secure" systems being built are designed to stop the compromise of information, pretty useless against an integrity attack (such as a virus). That's one of the reasons we are building the Type Enforcement mechanism; to stop viruses and ordinary Trojan Horses. Although this mechanism cannot "detect" or "screen" viruses, it can at least reduce them to ordinary Trojan Horse status (disallowing them anyway of propagating). Of course, if you audit, you should be able to pick up a virus attempting to propagate (due to rejected actions). Joseph ========================================================================= Date: Mon, 23 May 88 09:35:48 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1> Subject: implementing protection mechanisms I'd be interested in seeing some discussion about what virus protection mechanisms other people have actually implemented, particularly in microcomputer labs at universities. I don't just mean commercially available products; rather, any steps that are currently being taken at your site to try to prevent viruses from spreading there. Are you just using write protect tabs, etc., or are you also using some program(s) to try to detect them? Here at Lehigh University, we're currently implementing more and more Novell Local Area Networks - the network file server providing read-only access to all executable files on the LAN. We're also using notchless boot floppy disks for the workstations. Granted, there are ways of getting around the notchless floppies (via modifying hardware...), but they seem to be doing a pretty reasonable job (knock on wood :-). We're also currently evaluating a number of commercial products. So, what's everyone else doing? Opinions? Ken ------------------------------------------------------------------------ = Kenneth R. van Wyk = = = User Services Senior Consultant = Shocked! Shocked I am at = = Lehigh University Computing Center = this despicable act! = = Internet: <LUKEN@VAX1.CC.LEHIGH.EDU> = = = BITNET: <LUKEN@LEHIIBM1> = = ------------------------------------------------------------------------ ========================================================================= Date: Tue, 24 May 88 13:13:00 PDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: DBUERGER@SCU Subject: Comments on FLUSHOT PLUS I am forwarding these notes on FLUSHOT PLUS from Usenet.comp.sys.ibm.pc.general. I forgot to include the headers, but authors' net addresses are included. ------------------------------------- I was testing FLUSHOT Plus to see if it was worth the $10.00 fee the Author, Ross Greenberg is charging. I knew that a large number of hours had been put into the program. The documentation made it lk prettgood, even though it was a bit rambly. I created a FLUSHOT.DAT file, and put in 37 lines of the form C=filename When I loaded Flushot, I got a message saying that there was no room for a table, and the machine hung. I had not read the documentation closely enough. It turns out that you have to put a 'dummy' checksum in each line like this: C=filename[12345] Where 12345 is the dummy number. When flushot is started, it checksums the file, and reports the new number, which you have to write down and type in FOR EACH FILE! I then rewrote the FLUSHOT.DAT file with only two programs, command.com and a.bat checksummed. Flushot checked them on startup, but did not perform as advertised when I ran A.BAT, changed it, and ran it again. Flushot claims that it checksums files whenever they are loaded by MSDOS. I guess this does not apply to BATCH files. I was going to test checksumming of .EXE files, but FLUSHOT trashed my CMOS ram. FLUSHOT PROTECTS CMOS RAM ? Finally, I added two more lines to FLUSHOT.DAT with dummy checksums. I restarted FLUSHOT and got the following message: CMOS RAM HAS BEEN CHANGED. Y TO CONTINUE, ANY OTHER KEY TO PROCEED Followed by a long garbled bunch of characters!. Naturally, when I rebooted I could not boot from the Hard Disk, until I restored the setup information. My CMOS ram was trashed by FLUSHOT! I hoped that no damage had been performed to my FAT!. I then restored my ram with a CMOS-SAV progam which I wrote for such a purpose, and reloaded flushot. I then ran a program which zeroed out my CMOS ram using MS C outp() function, without a whimper from FLUSHOT. Note that I had no TSR'S present when this happened. I have a Leading Edge AT clone (Made by Mitsubishi, same as SPERRY IT). I am running DOS 3.1. I considered the possibility of Ross Greenberg enforcing his $10.00 fee by putting counters into flushot (since I had to restart it each time I changed anything in the FLUSHOT.DAT file and did this a number of times) and put the idea aside. (That was a pretty virulent dissertation in the manual about *worms*, maybe he thinks that people who don't buy his software are *worms*?!? :-) What I think Ross will accomplish by these threats, rewards, challenges is ENCOURAGE scores of copycats to write viruses to beat flushot (which is buggy). My conclusion is that FLUSHOT Plus does not perform as advertised (in my case, anyway) and I would not use it or even trust it with my data. The checksum protection is quite limited in number of files, and the method of entering the checksum is quite painful. The bugs in the program might be excusable if the program was public domain or shareware in the sense that you pay for it only if you think it is valuable (not if you use it, since technically, I owe Ross Greenberg $10 since I used it) . I think that it tries to do too much, and ends up doing too little, even the wrong thing altogether. This shows poor design and testing practice. When I support a shareware program, I am not paying the author for his time, I am paying for a finished product. And a finished product, FLUSHOT PLUS is not ! The above is my opinion, and no-one is liable for it but myself. I reserve the right to deny everything. Matt Cohen (matt@psuhcx) ------------------------------------------------- As promised, I forwarded matt@psuhcx (Matt Cohen)'s letter to Ross. Here's his reply: "Well, Matt, I'm sorry that you found the program to be less than you expected. You certainly got your money's worth, though, didn't you? Look, the program does try to do a lot. One area I'v had consistant trouble with has been CMOS. It'll get pulled in the next release. Not because some people didn;t find it useful. Just because the bitching from the people who had problems with it isn't worth the lousy $10 that the other people pay. If you don't like it, don't use it. I'm certain that I won;t lose any sleep over it. You might want to consider using one of the commercial products. I understand that at least one of them costs about $200. But, since you have to pay them in advance, I would assume that you'd not even consider such a thing. I ask people to contact me if they have a problem. I guess that part of the manual (the one with my phone number) must have escaped your astute observations as well as the "How to Use Flu_Shot" section must have. I know!! Your printer was out of paper! Well, just for you Matt, I'll print out a copy here and send it to you --- if you pay the postage. But, I guess with people like you around, I should just stop enhancing FLU_SHOT, or trying to protect *you* from the bad guys. Hell, I can't even protect you from yourself. Have a nice day, Matt." Erik Bailey | CompuServe | 7 Oak Knoll | (ARPA/USENET courtesy of ihnp4!think!ejb | PCMagNet | Arlington, MA 02174 | Thinking Machines Corp., ejb@think.com | 72261,3275 | (617) 643-0732 | First St, Cambridge, MA) do headache -> take 1 aspirin od "This terminates one way or another" -Dijkstra %%% End of forwarded messages David Buerger dbuerger@scu.bitnet ========================================================================= Date: Tue, 24 May 88 16:55:36 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1> Subject: More Flu_Shot woes I just saw another interesting Flu_Shot related bug report on the Usenet and I thought that I'd forward it here. The report goes into quite some detail as to specific bugs in various versions of Flu_Shot, including Flu_Shot+ 1.2. I hope that these bugs get fixed in a future release! Here's the forwarded message: >From: Glenn Larsen <glarsen@note.nsf.gov> >I had only one problem with Flu Shot 3 which was downloaded from SIMTEL >in Nevada. The problem was when using the option to protect the CMOS were >configuration information is stored with battery backup. Here in Albuquerque a local BBS SYSOP complained that FLUSHOT3 was actually a Trojan Horse program itself and was responsible for trashing his hard disk. Since it seemed like a legit program to me, based on the well documented sources of the program uploaded to SIMTEL20, I decided to take a little time and dis-assemble FLUSHOT3 and see if I could see any trouble. What I found was a program that, in my opinion, was loaded with bugs. One of the bugs I found was in the CMOS restore section: FLUSHOT3 screws up and replaces the ES register with the DS value when it returns from this routine. Summary of BUGS and/or omissions in FLUSHOT3 detected as of May 1, 1988: Bugs which can cause significant damage: 1. Stack corrupted in Int 26h handler: should return via RETF, which should leave flags on stack, but instead returns via RETF 2, thereby discarding flags. 2. Restoring CMOS memory after checking improperly restores the es segment register : es is replaced by ds 3. Program assumes direction flag is cleared (forward). Less damaging bugs: 4. Incorrect memory size (2 times amount req'd) in install 5. Interrupts are enabled for no reason in FCB test Condom holes: Bugs or ommissions that make program ineffective 6. Incorrect jmp instruction disables ASCIIZ rename checking 7. No check of AT bios int 13h "Write long" call (0bh) No checks for XT int 13h format calls 6 and 7 8. No accommodation for extended FCB format 9. No checks for direct IO via IOCTL call 44h 10. Program fails to detect FCB file delete and renaming functions that can affect critical files if wild cards are used. Loose ends: 11. Invalid error codes returned by int13h and int26h 12. Error code returned by failed FCB calls is unknown 13. Failures are not handled consistently - FCB calls return to program while others force a program terminate. 14. No checks for existence of CMOS RAM before reading and/or attempting to restore it. What happens on non AT's? [Since the user has to specifically request this check, one could argue it would be his/her own fault to invoke it on a machine that doesn't have the CMOS memory.] FluShot Plus, version 1.2 is significantly better, but it still has some problems: What I've found as of May 14, 1988: Bugs which can cause significant damage: 1. Stack corrupted in Int 26h handler (fails to leave old flags on stack as it should) Condom holes: Bugs or omissions that make program ineffective 2. No check of XT bios int 13h format functions 6 and 7 3. No accommodation for extended FCB format 4. No checks for direct IO via IOCTL call 44h Loose ends: 5. Invalid error codes returned by int 13h and int 26h failures 6. No checks for existence of CMOS RAM before reading and/or attempting to restore it. What happens on non AT's? [Since the user has to specifically request this check, one could argue it would be his/her own fault to invoke it on a machine that doesn't have the CMOS memory.] 7. Overall the program coding is bit sloppy. Since it doesn't make any attempt to optimize usage of the segment registers, it is a bit longer and slower than it needs to be. Final comments: What else can I say? I'm not going to claim to be the world's finest programmer and that I could do a better job. I may well be dead wrong in identifying some of the code as bugs. However I would suggest that if you are planning on using FLUSHOT xxxx, back up your hard disk first. PS: I downloaded the latest FSP_12.ARC from SIMTEL20 tonight to make sure that it was the same as what we had gotten off local boards here in Albuquerque. Unfortunately, the FSP.COM file was different! A quick check, however, reveals that the only difference was the addition of a CMP AL,"?" and JE xyz pair of instructions in the filename compare subroutine. The Int 26h stack bug was still there. Albq. version of FSP.COM: 10309 bytes CRC = BDCE 27 April 88 SIMTEL20 version : 10313 bytes CRC = 9723 27 April 88 Peter Esherick Sandia National Labs, Albuquerque <esheric@sandia-2.arpa> ------------------------------------------------------------------------ = Kenneth R. van Wyk = = = User Services Senior Consultant = Shocked! Shocked I am at = = Lehigh University Computing Center = this despicable act! = = Internet: <LUKEN@VAX1.CC.LEHIGH.EDU> = = = BITNET: <LUKEN@LEHIIBM1> = = ------------------------------------------------------------------------ ========================================================================= Date: Wed, 25 May 88 08:37:49 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1> Subject: well... Well, this isn't a virus per se, but I thought I'd mention it here because it spread over so much of the Usenet that it's become a major annoyance... Yesterday, a student on the Usenet sent out a request for money to further his education. He's requesting that each person reading his message sends him $1.00 - kind of like a chain letter... He sent this out to *MANY* major Usenet discussion lists. While reading Usenet news this morning, I probably saw his posting on about 20 different news groups. Granted, this poor starving student probably (!) deserves money to continue to go to college. But, I'd hate to see this sort of thing set a precedent on e-mail forums such as VIRUS-L and those on the Usenet. It'd become as bad as the CHRISTMA EXEC - everyone would be sending out this sort of junk mail over the networks which would undoubtedly cause lots of congestion, to say the least. Sort of a human nature virus...? Ken P.S. For obvious reasons, I didn't want to re-post the student's message here. ------------------------------------------------------------------------ = Kenneth R. van Wyk = = = User Services Senior Consultant = Shocked! Shocked I am at = = Lehigh University Computing Center = this despicable act! = = Internet: <LUKEN@VAX1.CC.LEHIGH.EDU> = = = BITNET: <LUKEN@LEHIIBM1> = = ------------------------------------------------------------------------ ========================================================================= Date: Wed, 25 May 88 19:34:52 GMT Reply-To: Malcolm Ray <malcolm@JVAX.CLP.AC.UK> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> Comments: Warning -- original Sender: tag was malcolm@JVAX.CLP.AC.UK From: MALCOLM@JVAX.CLP.AC.UK Subject: Slight irreverence It certainly seems that viruses have taken a strong hold in the States. As yet the UK has got off *relatively* lightly (howls of rage expected from unfortunate UK victims :-). We'd like to warn our students and staff of the dangers, and teach them some basic hygiene, but it's difficult to do so without contributing to the panic and hype. Gentle reader, how does one pitch the documentation? Speaking of hype, I think the best parody of an OTT virus story came from a friend of mine (who shall for the moment remain nameless, since I don't have his permission for reposting). Please don't think I'm taking the subject lightly; just staying sane: > I actually had to replace the transformer in the power supply of > my PC after a really nasty virus had hacked its way onto it. My > supplier said I would have to replace major sections of the > plastic moulding around the monitor, but it looks like I got away > with it. I'm pretty alert when it comes to viruses: I actually > nearly caught the blighter before it got to the transformer, but > the bloody thing slipped up the secondary winding before I could > zap it. Think of that next time you hear of some punter having to replace ROMs because some nasty program had run riot! ------------------------------------------------------------------------ Malcolm Ray JANET: malcolm@uk.ac.clp.jvax Senior Systems Officer BitNet: malcolm@jvax.clp.ac.uk City of London Polytechnic No other routes please! Isn't it strange how few UK correspondents bother with disclaimers? ========================================================================= Date: Wed, 25 May 88 20:24:52 CST Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: James Ford <JFORD1@UA1VM> Subject: Re: Question about CRC protection In-Reply-To: Message of Fri, 13 May 88 12:20:00 EST from <GILL@QUCDNAST> ========================================================================= Date: Thu, 26 May 88 08:03:16 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Joe McMahon <XRJDM@SCFVM> Subject: Mac Virus Clearinghouse Hello all. We've set up a sort of clearinghouse for Macintosh anti-viral software on our LISTSERV. The files we are collecting are essentially descriptions of known viruses, detection programs, eradication programs, and prevention programs. To access this, TELL LISTSERV AT SCFVM INDEX PUBLIC. That will give you a list of the files available. We intend to stay on top of this -- we're being cautious, but not panicing. We have only have 4 systems out of (my guess) a couple hundred invaded, but it always pays to have the software available. --- Joe M. ========================================================================= Date: Fri, 27 May 88 15:35:25 GMT Reply-To: Malcolm Ray <malcolm@JVAX.CLP.AC.UK> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> Comments: Warning -- original Sender: tag was malcolm@JVAX.CLP.AC.UK From: MALCOLM@JVAX.CLP.AC.UK Subject: RE: Slight irreverence A slip of the fingers caused Ken to send the following to me personally instead of to the list. At his request I'm forwarding it. ==== Bite here ==== From: "Kenneth R. van Wyk" <LUKEN@EARN.LEHIIBM1> 27-MAY-1988 14:24 To: MALCOLM Subj: Re: Slight irreverence Received: from UKACRL by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 3655; Fri, 27 May 88 14:25:01 BS Received: from LEHIIBM1.BITNET by UKACRL.BITNET (Mailer X1.25) with BSMTP id 3654; Fri, 27 May 88 14:25:00 B Received: by LEHIIBM1 (Mailer X1.24) id 0769; Fri, 27 May 88 09:11:39 EDT Date: Fri, 27 May 88 09:01:31 EDT From: "Kenneth R. van Wyk" <LUKEN@EARN.LEHIIBM1> Subject: Re: Slight irreverence To: Malcolm Ray <malcolm@UK.AC.CLP.JVAX> In-Reply-To: Message of Wed, 25 May 88 19:34:52 GMT from <MALCOLM@JVAX.CLP.AC.U >We'd like to warn our students and staff >of the dangers, and teach them some basic hygiene, but it's difficult to >do so without contributing to the panic and hype. Gentle reader, how does >one pitch the documentation? I think that your example of hype (the reported virus "frying" the transformer and all...) is about the best example of how *NOT* to educate your students and staff about viruses! Perhaps truth would be a much better approach; present the facts, along with common sense precautions that people can take to reduce their risk of being stung by a virus. Give them examples of what existing viruses have done, and how far they've spread (the Brain virus seems as good an example as any), and tell them how a virus spreads (by executing an infected program - including the operating system/boot tracks, NOT by things such as two disks coming in physical contact with one another). In short, take the myths out of viruses for your users. Explain to them that, by sharing programs with other users (either via disk swapping or downloading from bulletin boards, etc.), they're taking the risk that they may execute a program which is infected. Above all, tell them to make backups of all of their data *FREQUENTLY*, and to keep all shrink wrap original disks in a safe place with their write protect tabs on. Anyone have anything to add to this? Regards, Ken ------------------------------------------------------------------------ = Kenneth R. van Wyk = = = User Services Senior Consultant = This page intentionally = = Lehigh University Computing Center = left blank. = = Internet: <LUKEN@VAX1.CC.LEHIGH.EDU> = = = BITNET: <LUKEN@LEHIIBM1> = = ------------------------------------------------------------------------ ========================================================================= Date: Fri, 27 May 88 16:05:49 GMT Reply-To: Malcolm Ray <malcolm@JVAX.CLP.AC.UK> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> Comments: Warning -- original Sender: tag was malcolm@JVAX.CLP.AC.UK From: MALCOLM@JVAX.CLP.AC.UK Subject: RE: Slight irreverence Ken, I had no intention of letting that spoof anywhere near our users! It was intended for the sophisticates who can spot hype when they see it. My point was exactly what you said: naive users (I don't use the term pejoratively) are *not* getting the truth, because some people who should know better (mostly in the computer press) are hyping it up. I had an example of this today: a friend who's involved in a research project about distributed operating systems tells me that his team leader is giving a talk on his work. The other contributor is a computer journalist noted for his virus stories, and... well, on second thoughts, I don't want to be libellous. The point is that people *like* virus stories - they're becoming part of modern folklore (albeit with a slightly limited audience), like alligators in the sewers and [fill in your favourite tall story here]. Hands up who's read "Shockwave Rider" by John Brunner. Enjoyable book, right? Think about why. Let's face it, although I'm sure we're all agreed that virus-writing is very irresponsible and should be countered, we all enjoy a good story about the chaos caused (as long as it's someone else's chaos, or we've put it behind us). But their are people who *believe* there are alligators down there... Again, this is not to diminish anyone's problems. If your site has been brought to its knees, commiserations :-(. I just don't want to see the proliferation of what a colleague called "the virus scare virus". Let's keep this list part of the cure, not part of the disease. ------------------------------------------------------------------------ Malcolm Ray JANET: malcolm@uk.ac.clp.jvax Senior Systems Officer BitNet: malcolm@jvax.clp.ac.uk City of London Polytechnic No other routes please! All seems infected that the infected spy, As all looks yellow to the jaundiced eye -- Alexander Pope ========================================================================= Date: Fri, 27 May 88 12:17:39 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Alan J Rosenthal <flaps@gpu.utcs.utoronto> Subject: write-protect tabs Recently, Kenneth R. van Wyk advised VIRUS-L readers to advise users, among other things, > to keep all shrink wrap original disks in a safe place with their > write protect tabs on. I would like to point out that many computer users are not aware that write protection for floppy disks is often implemented in software and therefore can be ignored by a malicious program. Any discussion of write-protecting disks should mention this. [The program also has to re-implement the disk io libraries, so this does greatly increase its complexity, but many virus programs are quite sophisticated!] In particular, the write protection on Macintosh computers is definitely implemented in software, and I seem to vaguely remember that it is on the IBM-PC as well. So there is hardware to read whether the disk is write-protected or not, and a responsible program checks this before writing. Needless to say, I think this is a big mistake and can't see why someone would build a disk drive like that. Alan J Rosenthal, flaps at utorgpu ========================================================================= Date: Tue, 24 May 88 11:09:00 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> Comments: Resent-From: "Joseph M. Beckman" <Beckman@DOCKMASTER.ARPA> Comments: Originally-From: "Joseph M. Beckman" <Beckman@DOCKMASTER.ARPA> From: "Joseph M. Beckman" <Beckman@DOCKMASTER.ARPA> Subject: Re: hunting up infected files In-Reply-To: Message of 9 May 1988 11:05 edt from Karl-L. Noell As an employee of the National Computer Security Center, I must point out that we do *NOT* attempt to track perpetrators for prosecution or for *ANY* other reason! We are not a law enforcement Agency, and are prohibited by law to take any such action. We are interested in tracking the viruses (or ordinary Trojan Horses) as they infect different sites. As a matter of professional interest, I would be curious as to the motivations of perpetrators of malicious code, or whether they are members of "Hacker Clubs;" but that is information that may be conveyed without identifying the people/organizations involved. Joseph ========================================================================= Date: Fri, 27 May 88 17:50:47 GMT Reply-To: Malcolm Ray <malcolm@JVAX.CLP.AC.UK> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> Comments: Warning -- original Sender: tag was malcolm@JVAX.CLP.AC.UK From: MALCOLM@JVAX.CLP.AC.UK Subject: RE: write-protect tabs IBM-PC floppy write-protect logic is hardware. If a disk is write-protected, it's *safe*. ------------------------------------------------------------------------ Malcolm Ray JANET: malcolm@uk.ac.clp.jvax Senior Systems Officer BitNet: malcolm@jvax.clp.ac.uk City of London Polytechnic No other routes please! Most people won't realise that writing is a craft. You have to take your apprenticeship in it like anything else. -- Katherine Anne Porter ========================================================================= Date: Fri, 27 May 88 13:23:07 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1> Subject: Monthly (starting now) greeting. [ Last (and first) modified 27-May-88 - Ken van Wyk ] Welcome! This is the monthly introduction posting for VIRUS-L, primarily for the benefit of any newcomers. Apologies to all subscribers who've already read this in the past (you'll only have to see it once a month, and you can, if you're quick, press the purge key...:-). What is VIRUS-L? It is an electronic mail discussion forum for sharing information about computer viruses. Discussions should include (but not necessarily be limited to): current events (virus sightings), virus prevention (practical and theoretical), and virus questions/answers. What isn't VIRUS-L? A place to spread hype about computer viruses; we already have the Press for that. :-) A place to sell things, to panhandle, or to flame other subscribers. If anyone *REALLY* feels the need to flame someone else for something that they may have said, then the flame should be sent directly to that person and/or to the list moderator (that'd be me, <LUKEN@LEHIIBM1.BITNET>). How do I get on the mailing list? Well, if you're reading this, chances are *real good* that you're already on the list. However, perhaps this document was given to you by a friend or colleague... So, to get onto the VIRUS-L mailing list, send a mail message to <LISTSERV@LEHIIBM1.BITNET>. In the body of the message, say nothing more than SUB VIRUS-L your name. LISTSERV is a program which automates mailing lists such as VIRUS-L. As long as you're either on BITNET, or any network accessible to BITNET via gateway, this should work. Within a short time, you will be placed on the mailing list, and you will get confirmation via e-mail. How do I get OFF of the list? If, in the unlikely event, you should happen to want to be removed from the VIRUS-L discussion list, just send mail to <LISTSERV@LEHIIBM1.BITNET> saying SIGNOFF VIRUS-L. People, such as students, whose accounts are going to be close (like over the summer...) - PLEASE signoff of the list before you leave. Also, be sure to send your signoff request to the LISTSERV and not to the list itself. How do I send a message to the list? Just send electronic mail to <VIRUS-L@LEHIIBM1.BITNET> and it will automatically be redistributed to everyone on the mailing list. By default, you will not receive a copy of your own letters. If you wish to do so, send mail to <LISTSERV@LEHIIBM1.BITNET> saying SET VIRUS-L REPRO. What does VIRUS-L have to offer? All submissions to VIRUS-L are stored in monthly log files which can be downloaded by any user on (or off) the mailing list. There is also a small archive of some of the public anti-virus programs which are currently available. This archive, too, can be accessed by any user. All of this is handled automatically by the LISTSERV here at Lehigh University (<LISTSERV@LEHIIBM1.BITNET>). How do I get files from the LISTSERV? Well, you'll first want to know what files are available on the LISTSERV. To do this, send mail to <LISTSERV@LEHIIBM1.BITNET> saying INDEX VIRUS-L. Note that filenames/extensions are separated by a space, and not by a period. Once you've decided which file(s) you want, send mail to <LISTSERV@LEHIIBM1.BITNET> saying GET filename filetype. For example, GET VIRUS-L LOG8804 would get the file called VIRUS-L LOG8804 (which happens to be the monthly log of all messages sent to VIRUS-L during April, 1988). What is uuencode/uudecode, and why do I need them? Uuencode and uudecode are two programs which convert binary files into text (ASCII) files and back again. This is so binary files can be easily transferred via electronic mail. Many of the files on this LISTSERV are binary files which are stored in uuencoded format (the file types will be UUE). Both uuencode and uudecode are available from the LISTSERV. Uudecode is available in BASIC and in Turbo Pascal here. Uuencode is available in Turbo Pascal. Also, there is a very good binary-only uuencode/uudecode package on the LISTSERV which is stored in uuencoded format. Why have posting guidelines? To keep the discussions on-track with what the list is intended to be; a vehicle for virus discussions. This will keep the network traffic to a minimum and, hopefully, the quality of the content of the mail to a maximum. No one wants to read personal flames ad nausium, or discussions about the pros and cons of digest-format mailing lists, etc. What are the guidelines? As already stated, there will be no flames on the list. Anyone sending flames to the entire list must do so knowing that he/she will be removed from the list immediately. Same goes for any commercial plugs or panhandling. Submissions should be directly or indirectly related to the subject of computer viruses. Thank-you for your time and for your adherance to these guidelines. Comments and suggestions, as alway, are invited. Please address them to me, <LUKEN@LEHIIBM1.BITNET> or <LUKEN@VAX1.CC.LEHIGH.EDU>. Ken van Wyk ------------------------------------------------------------------------ = Kenneth R. van Wyk = = = User Services Senior Consultant = This page intentionally = = Lehigh University Computing Center = left blank. = = Internet: <LUKEN@VAX1.CC.LEHIGH.EDU> = = = BITNET: <LUKEN@LEHIIBM1> = = ------------------------------------------------------------------------ ========================================================================= Date: Fri, 27 May 88 19:31:00 LCL Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Michael Wagner +49 228 8199645 <WAGNER@DBNGMD21> Subject: Re: write-protect tabs > IBM-PC floppy write-protect logic is hardware. If a disk is > write-protected, it's *safe*. I believe the above statement to be correct; however, many people would disagree. I have been told that the confusion comes from the fact that there are two levels of protection on some floppy schemes. The write protect line is sensed and available for the software, so the software can produce a nice message. The line is also used, inside the drive itself, to shut down the write-current supply, so that, even if the controller *thinks* it is writing, it isn't. I believe this is the scheme used on the PC. Disclaimer: I don't have a PC, nor access to the documents to prove or disprove this 'fact'. Michael ========================================================================= Date: Fri, 27 May 88 13:15:51 CDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: CB Lih <CL06076@UAFSYSB> Subject: Write protect So what's the deal? Can software override the Mac protect tab? Are y'all sure about IBM? What about other computers? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Sincerly, and I mean that, =---> CB Lih <---= User Services -> Computing Services -> University of Arkansas -> Fayetteville CL06076@UAFSYSB Disclaimer: There's a hole in my ozone layer. ========================================================================= Date: Fri, 27 May 88 15:57:38 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Terry Sanderson <SANDERS@UTORONTO> Subject: Re: write-protect tabs In-Reply-To: Message of Fri, 27 May 88 19:31:00 LCL from <WAGNER@DBNGMD21> Having stated this on the list once before, the topic has again arisen. IBM PC Floppy disks CANNOT be written to when there is a WRITE-PROTECT tab on the disk. I DO have access to technical docs, schematics, etc., and there is NO WAY the software can change this fact. The hardware provides a signal to the operating system that there is in fact a write-protect tab on the disk, but it cannot chance or override the protection. I hope this clears up any questions. Terry P. Sanderson P.Eng. sanders@utoronto.bitnet sanders@gpu.utcs.toronto.edu ========================================================================= Date: Fri, 27 May 88 16:30:00 EST Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: PHREADDE <PDAVIS@BINGVAXA> Subject: bad tabs I disagree, on the IBM you can write on disks protected with CERTAIN write protect tabs. A while back, certain manufacturers produced red see-thru tabs that provided no protection. Those manufacturers have switched back to silver-backed black tabs. I have used the old ones and definitly written to files. This, however, should not be a problem currently. No one that I know of produces these thin red tabs now. If you have the old ones, discard them; they are ineffectual. And to all readers and contributors on this list, I would like to thank you for your work and questions. A virus did hit our school, and was completely vanquished within a few days. The methods that we used now help us protect our classroom software against accidental mistakes as well as future viruses. Public software is always vunerable to tapering, but we feel much more protected these days. Thanks again. Phreadde Davis State University of NY - Binghamton ========================================================================= Date: Fri, 27 May 88 14:44:00 PDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: WATKINS@UCRVMS Subject: Write Protect No, as far as I know (which is reasonably far), a Macintosh cannot override a write protect tab (or whatever the term is for 3.5" disks); I mean, unless it's been concealed all this time it can't be done.. And a couple cents worth (I hope) of stuff on defending against Mac viruses...maybe this was covered earlier, but remember that there are some resources in the system file that are duplicated in rom (for instance, chicago 12, geneva 12 (I think), some wdefs, etc. Now if I was to write a virus, I'd think that these places would be pretty keen for hiding my code. (hmm, maybe I should clarify a bit, what happens is the mac first checks to see if a resource is in rom and uses it if it can, so if you garbaged up the fonts with your virus code, nobody would notice. It's pretty easy to bypass the rom resources though so you could load this stuff and jump to it pretty easily...) I hope that made some sense... Kevin Lund watkins@ucrvms.bitnet kevin@hope.uucp ========================================================================= Date: Tue, 24 May 88 08:01:00 MDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> Comments: Warning -- original Sender: tag was KPETERSEN@SIMTEL20.ARPA From: Keith Petersen <W8SDZ@SIMTEL20.ARPA> Subject: FLUSHOT-Plus withdrawn from SIMTEL20 archives I have decided to remove FluShot-Plus from our SIMTEL20 archives because of the continuing problem of programming bugs. It is *not* a Trojan or Virus. The author just needs to get his bugs fixed. I recommend to all recipients of this message that they discontinue use of *any* version of Flushot or Flushot-Plus. --Keith Petersen Maintainer of the MSDOS archives at SIMTEL20.ARPA ---forwarded message--- Date: Tuesday, 24 May 1988 08:20-MDT From: <esheric at sandia-2.arpa> Reply-To: <esheric at sandia-2.arpa> To: w8sdz <w8sdz> cc: esheric at sandia-2.arpa Re: Flushot plus bugs >From: Glenn Larsen <glarsen@note.nsf.gov> >I had only one problem with Flu Shot 3 which was downloaded from SIMTEL >in Nevada. The problem was when using the option to protect the CMOS were >configuration information is stored with battery backup. Here in Albuquerque a local BBS SYSOP complained that FLUSHOT3 was actually a Trojan Horse program itself and was responsible for trashing his hard disk. Since it seemed like a legit program to me, based on the well documented sources of the program uploaded to SIMTEL20, I decided to take a little time and dis-assemble FLUSHOT3 and see if I could see any trouble. What I found was a program that, in my opinion, was loaded with bugs. One of the bugs I found was in the CMOS restore section: FLUSHOT3 screws up and replaces the ES register with the DS value when it returns from this routine. Summary of BUGS and/or omissions in FLUSHOT3 detected as of May 1, 1988: Bugs which can cause significant damage: 1. Stack corrupted in Int 26h handler: should return via RETF, which should leave flags on stack, but instead returns via RETF 2, thereby discarding flags. 2. Restoring CMOS memory after checking improperly restores the es segment register : es is replaced by ds 3. Program assumes direction flag is cleared (forward). Less damaging bugs: 4. Incorrect memory size (2 times amount req'd) in install 5. Interrupts are enabled for no reason in FCB test Condom holes: Bugs or ommissions that make program ineffective 6. Incorrect jmp instruction disables ASCIIZ rename checking 7. No check of AT bios int 13h "Write long" call (0bh) No checks for XT int 13h format calls 6 and 7 8. No accommodation for extended FCB format 9. No checks for direct IO via IOCTL call 44h 10. Program fails to detect FCB file delete and renaming functions that can affect critical files if wild cards are used. Loose ends: 11. Invalid error codes returned by int13h and int26h 12. Error code returned by failed FCB calls is unknown 13. Failures are not handled consistently - FCB calls return to program while others force a program terminate. 14. No checks for existence of CMOS RAM before reading and/or attempting to restore it. What happens on non AT's? [Since the user has to specifically request this check, one could argue it would be his/her own fault to invoke it on a machine that doesn't have the CMOS memory.] FluShot Plus, version 1.2 is significantly better, but it still has some problems: What I've found as of May 14, 1988: Bugs which can cause significant damage: 1. Stack corrupted in Int 26h handler (fails to leave old flags on stack as it should) Condom holes: Bugs or omissions that make program ineffective 2. No check of XT bios int 13h format functions 6 and 7 3. No accommodation for extended FCB format 4. No checks for direct IO via IOCTL call 44h Loose ends: 5. Invalid error codes returned by int 13h and int 26h failures 6. No checks for existence of CMOS RAM before reading and/or attempting to restore it. What happens on non AT's? [Since the user has to specifically request this check, one could argue it would be his/her own fault to invoke it on a machine that doesn't have the CMOS memory.] 7. Overall the program coding is bit sloppy. Since it doesn't make any attempt to optimize usage of the segment registers, it is a bit longer and slower than it needs to be. Final comments: What else can I say? I'm not going to claim to be the world's finest programmer and that I could do a better job. I may well be dead wrong in identifying some of the code as bugs. However I would suggest that if you are planning on using FLUSHOT xxxx, back up your hard disk first. PS: I downloaded the latest FSP_12.ARC from SIMTEL20 tonight to make sure that it was the same as what we had gotten off local boards here in Albuquerque. Unfortunately, the FSP.COM file was different! A quick check, however, reveals that the only difference was the addition of a CMP AL,"?" and JE xyz pair of instructions in the filename compare subroutine. The Int 26h stack bug was still there. Albq. version of FSP.COM: 10309 bytes CRC = BDCE 27 April 88 SIMTEL20 version : 10313 bytes CRC = 9723 27 April 88 Peter Esherick Sandia National Labs, Albuquerque <esheric@sandia-2.arpa> ========================================================================= Date: Sat, 28 May 88 13:29:00 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Stan Horwitz <V4039@TEMPLEVM> Subject: Re: bad tabs In-Reply-To: Message of Fri, 27 May 88 16:30:00 EST from <PDAVIS@BINGVAXA> Write protect tabs to prevent tamporing of disks is plain silly. All any prankster need do is to remove the write protect tab from the disk to sabatage a disk. When done, it's a simple matter to stick a new write protect tab back on the damage disk. A better solution is to use notchless disks and write to them on a machine altered so it won't complain about the disk. If memory serves, I believe I have heard that write protect tabs can also fail when they are sqeezed or bent in a certain way due to age but I am not sure of this. Stan Horwitz Mainframe Consultant Disclaimer -- Who me? I didn't say that? V4039%TEMPLEVM.BITNET at cunyvm.cuny.edu Temple Univeristy Philadelphia, Pennsylvania USA ========================================================================= Date: Sat, 28 May 88 17:20:00 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> Comments: Resent-From: KPETERSEN@SIMTEL20.ARPA Comments: Originally-From: ihnp4!ho95e!wcs@ATT.ARPA (Bill.Stewart.<ho95c>) From: KPETERSEN@SIMTEL20.ARPA Subject: Warning: Flushot4 is a virus! A program called Flushot4 was recently seen on a BBS out west. Ross Greenberg's Flushot versions don't go up that high, and this one was apparently a virus advertising itself as vaccine. So if you see it, don't use it, don't trust anything from the machine it's on, call the operator of the machine you see it on, etc. -- # Thanks; # Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs # Computers - Nasty, disturbing, uncomfortable things! # Make you late for dinner. or breakfast. ========================================================================= Date: Sat, 28 May 88 19:06:50 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: David.Slonosky@QueensU.CA Subject: Naive virus questions 1) Is it possible to demount and mount the hard disk so that you can effectively work with the floppy drives and not have to worry about code being transferred to the hard disk? 2) Is it possible to design a virus that screws up the ROM? Hey, these may seem naive, but then I'm not a computer scientist by trade. ========================================================================= Date: Mon, 30 May 88 17:55:00 LCL Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Michael Wagner +49 228 8199645 <WAGNER@DBNGMD21> Subject: Re: write-protect tabs Terry Sanderson <SANDERS@UTORONTO> writes: > IBM PC Floppy disks CANNOT be written to when there is a > WRITE-PROTECT tab on the disk. > > I DO have access to technical docs, schematics, etc. The hardware > provides a signal to the operating system that there is ... a > write-protect tab on the disk, but it cannot ... override the > protection. Terry: Perhaps an overview description of the form of protection, where it is provided (in the drive itself, or in the interface hardware) and whether this protection can also be expected to be in clones would help clarify the situation. Michael ========================================================================= Date: Mon, 30 May 88 12:01:00 EST Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: GILL@QUCDNAST Subject: RE: Hard disk disable David Slonosky asked about a disable for a hard disk In answer to your submission to VIRUS-L (at least part 1), there is a program on the MSDOS disk called BOOTF. If I understand it correctly (i.e. read the manual), it will software disable the harddisk so that any program running from floppies doesn't see the harddisk. This was written because some old commercial programs used a copy-protection scheme that crashed their program when run on a machine with a harddisk. Really dumb, eh!! However, since this is a software disable, I suppose it can be circumvented by a virus checking for this kind of thing. Those more knowledgable could perhaps comment on that. ____________________________________ Arnold Gill | If you don't complain to those who | Queen's University at Kingston | implemented the problem, you have | gill @ qucdnast.bitnet | no right to complain at all ! | ------------------------------------ ========================================================================= Date: Tue, 31 May 88 07:39:31 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Kenneth Ng <ken@orion.cccc.njit.edu> Subject: write protect tab on floppies >From: MALCOLM@JVAX.CLP.AC.UK > >IBM-PC floppy write-protect logic is hardware. If a disk is write-prot >ected >it's *safe*. > Well, not always. I recall talk/flames several months back about a certain type of floppy disk drive (which one escapes me). Evidently the write protect hardware worked by sensing the reflection from the write protect tab to determine that the floppy was write protected. Evidently the designer never heard of black write protect tabs or of floppy disks that are manufactured without write protect slots. Remember to always check *EVERYTHING* the manufacturer claims before you need to. ========================================================================= Date: Tue, 31 May 88 10:52:07 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1> Subject: First of two forwarded submissions The following is taken from a newspaper people's magazine, and describes some effects found in viruses that are different that I had seen up till this time. Quoted without permission from Editor and Publisher, May 21, 1988 _Computer_Virus_Hits_First_U._S._Newspaper_ by Mark Fitzgerald A computer virus has finally infected a newspaper computer system. The Providence Journal-Bulletin discovered the virus late on Friday May 13 when reporter Froma Joselow's personal computer disc was destroyed, the newspaper's systems engineer, Peter Scheidler, stated. "Her file allocation table was overwritten in a rather unusual way - it was all zeros," Scheidler said in a telephone interview. "Then this message appeared." The message included the name of a Lahore, Pakistan company, "Brain Computer Services," a 1986 copyright, the name of the two brothers who own the store - Basit and Amjad - plus the address of the store and its telephone. In the middle was this chilling message: "Welcome to the Dungeon ... Beware of this VIRUS. Contact us for a vaccination." [The article goes on to say that about 100 disks were infected, that the virus was contained totally in the boot block and that overwriting of the boot block cleared the disks. Other information in the story is no news to us. The only new thing to me is that my understanding of this "Brain" virus is that it was harmless, apparently not so with this implementation. Len Levine len@evax.milw.wisc.edu ] ------------------------------------------------------------------------ = Kenneth R. van Wyk = = = User Services Senior Consultant = This page intentionally = = Lehigh University Computing Center = left blank. = = Internet: <LUKEN@VAX1.CC.LEHIGH.EDU> = = = BITNET: <LUKEN@LEHIIBM1> = = ------------------------------------------------------------------------ ========================================================================= Date: Tue, 31 May 88 10:53:45 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1> Subject: Second forwarded submission >IBM-PC floppy write-protect logic is hardware. If a disk is write-protected, >it's *safe*. Well, yes and no. If you mean that a virus cannot write to a hardware protected diskette, you are quite right (although one should never say never :-)). However, it should be pointed out that hardware write protection can fail to work. Most floppy drives detect the presence of a write-protect notch with a mechanical or optical device. These devices are subject to failure. As a case in point, we purchased some 5.25 inch red floppy diskettes that did not have write-protect notches. We wanted to distribute site-licensed software, while making sure the software was returned to use in the same condition as when checked out. In order for us to put the site-licensed software on the diskettes, we altered a floppy drive by temporarily removing the mechanical switch that determined whether the floppy was write-protected. In the process, we found that one of our *UNaltered* drives read this write-protected diskette! It turned out that this drive used an optical means of sensing the status of the write-protect notch, and the light traveled through the red jacket of the floppy diskette. Although the diskette was write-protected, the hardware failed to detect this. I understand that some translucent write-protect tabs cause the same problem. The point is that a write-protected diskette is not completely immune from infection. --------------------- John L. Cofer COFER@UTKVX1.BITNET ------------------------------------------------------------------------ = Kenneth R. van Wyk = = = User Services Senior Consultant = This page intentionally = = Lehigh University Computing Center = left blank. = = Internet: <LUKEN@VAX1.CC.LEHIGH.EDU> = = = BITNET: <LUKEN@LEHIIBM1> = = ------------------------------------------------------------------------ ========================================================================= Date: Tue, 31 May 88 10:55:14 EDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1> Subject: Did I say two? I meant three forwarded submissions... :-) RE: FLUSHOT4 IS VIRUS.... It is not. It is a hacked version of the program by Ross Greenberg; it is Trojan Horse since it does not replicate itself. Some chutzpahnik took a hacked version of TXT2COM utility for making executable text files. The hacked program does things that the original utility does not- like wipe out all files on the same drive from which it is run. The hacked TXT2COM was used on the FLUSHOT docs (which are ASCII) to make the FLUSHOT into the Trojan Horse. RE: Nomenclature.... A reminder that in discussing malicious programs on a serious level, it helps to keep our terms straight. Remember, the trait that makes a program a virus is its ability to replicate its code, usually INTO other, valid, programs. (A case of the un-common code. %-)) There are also automated Trojan Horses, such as the trouble- some version of CHRISMAS EXEC which are often called viruses. Some computer scientists have taken to calling these automated Trojans "bacteria". Also, it is good to remember that not all programs that wreck files, etc. are Trojans or viruses. There are a lot of buggy programs out there. For example, there is a debate about NOTROJ; some people have gotten burned by it, others have no problems. It may be that it was not designed to be harmful, but has bugs that make it harmful on many systems. RE: NAIVE QUESTIONS.... There no dumb questions that are asked (in the right place and time). The dumb question is the one that should have been asked but never was. As for the question about disconnecting the hard drive nad running floppies only is fesible and recommended for maxiumum protection while testing new programs. It is not a method suitable for everybody (sort of like GRAPE NUTS<Tm> cereal). But even malicious programs that can overide software hard disk write protects can not override an open circuit. The trouble is the setting up and the cases where the software needs the capacity of a hard disk. My dream scenario would be cheap disposible hard disks for testing purposes. Electronic Petri Dishes. Thank you, J.D. Abolins ------------------------------------------------------------------------ = Kenneth R. van Wyk = = = User Services Senior Consultant = This page intentionally = = Lehigh University Computing Center = left blank. = = Internet: <LUKEN@VAX1.CC.LEHIGH.EDU> = = = BITNET: <LUKEN@LEHIIBM1> = = ------------------------------------------------------------------------ ========================================================================= Date: Tue, 31 May 88 16:31:07 CDT Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1> Sender: Virus Discussion List <VIRUS-L@LEHIIBM1> From: Werner Uhrig <werner@rascal.ics.utexas.edu> Subject: Playboy virus - BEWARE! (thomas@uvabick (Thomas Fruin)) [comp.sys.mac] From: thomas@uvabick.UUCP (Thomas Fruin) Newsgroups: comp.sys.mac Subject: Playboy virus - BEWARE! Message-ID: <258@uvabick.UUCP> Date: 30 May 88 23:19:47 GMT Through a dealer I heard that a new Macintosh virus had been sighted here in the Netherlands, in Utrecht to be precise. It was called Playboy or something similar, and after double clicking rapidly started showing you pictures of benevolent nude girls, while it was malevolently busy erasing your hard disk ... This is all I know. Just be sure to fight your desire to launch this nasty. -- Thomas Fruin fruin@hlerul5.BITNET University of Leiden thomas@uvabick.UUCP University of Amsterdam dibs@well.UUCP hol0066.AppleLink 2:512/114.FidoNet The Netherlands